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POLICY: PASCAL NEWS (17-Mar-80) 

* Pascal News is the official but informal publication of the User's Group. 

* Pascal News contains all we (the editors) know about Pascal; we use it as 
the vehicle to answer all inquiries because our physical energy and 
resources for answering individual requests are finite. As PUG grows, we 
unfortunately succumb to the reality of: 

1. Having to insist that people who need to know "about Pascal" join PUG 
and read Pascal News - that is why we spend time to produce it! 

2. Refusing to return phone calls or answer letters full of questions - we 
will pass the questions on to the readership of Pascal News . Please 
understand what the collective effect of individual inquiries has at the 
"concentrators" (our phones and mailboxes). We are trying honestly to say: 
"We cannot promise more that we can do." 

* Pascal News is produced 3 or 4 times during an academic year; usually in 
September , November, February, and May. 

* ALL THE NEWS THAT'S FIT, WE PRINT. Please send material (brevity is a 
virtue) for Pascal News single- spaced and camera- ready (use dark ribbon and 
18.5 cm lines!) 

* Remember: ALL LETTERS TO US WILL BE PRINTED UNLESS THEY CONTAIN A REQUEST 
TO THE CONTRARY. 

* Pascal News is divided into flexible sections: 

POLICY - explains the way we do things (ALL-PURPOSE COUPON, etc.) 

EDITOR'S CONTRIBUTION - passes along the opinion and point of view of the 
editor together with changes in the mechanics of PUG operation, etc. 

HERE AND THERE WITH PASCAL - presents news from people, conference 
announcements and reports, new books and articles (including reviews), 
notices of Pascal in the news, history, membership rosters, etc. 

APPLICATIONS - presents and documents source programs written in Pascal 
for various algorithms, and software tools for a Pascal environment; news 
of significant applications programs. Also critiques regarding 
program/ algorithm certification, performance, standards conformance, 
style, output convenience, and "general design. 

ARTICLES - contains formal, submitted contributions (such as Pascal 
philosophy, use of Pascal as a teaching tool, use of Pascal at different 
computer installations, how to promote Pascal, etc.). 

OPEN FORUM FOR MEMBERS - contains short, informal correspondence among 
members which is of interest to the readership of Pascal News . 

IMPLEMENTATION NOTES - reports news of Pascal implementations: contacts 
for maintainers, implementors, distributors, and documentors of various 
implementations as well as where to send bug reports. Qualitative and 
quantitative descriptions and comparisons of various implementations are 
publicized. Sections contain information about Portable Pascals, Pascal 
Variants, Feature-Implementation Notes, and Machine-Dependent 
Implementations . 



ALL-PURPOSE COUPON 



(17-Mar-80) 



Pascal User's Group, c/o Rick Shaw 
Digital Equipment Corporation 
5775 Peachtree Dunwoody Road 
Atlanta, Georgia 30342 USA 

**N0TE** 

Membership is for an academic year (ending June 30th). 

Membership fee and All Purpose Coupon is sent to your Regional 

Representative. 

See the Policy section on the reverse side for prices and 

ALTERNATE ADDRESS if you are located in the European or 

Australasian Regions. 

Membership and Renewal are the same price. 

The U. S. Postal Service does not forward Pascal News. 



] Enter me as a new member for: 
] Renew my subscription for: 

] Send Back Issue(s) 
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] My new/correct address/phone is listed below 

] Enclosed please find a contribution, idea, article or opinion 
which is submitted for publication in the Pascal News . 

] Comments: 




NAME 
ADDRESS 



PHONE 

COMPUTER^ 

DATE 



JOINING PASCAL USER f S GROUP? 

Membership is open to anyone: Particularly the Pascal user, teacher, 
maintainer, implementor, distributor, or just plain fan. 

Please enclose the proper prepayment (check payable to "Pascal User f s 
Group 11 ); we will not bill you. 

Please do not send us purchase orders; we cannot endure the paper work! 
When you join PUG any time within an academic year: July 1 to June 30, you 
will receive all issues of Pascal News for that year. 

We produce Pascal News as a means toward the end of promoting Pascal and 
communicating news of events surrounding Pascal to persons interested in 
^Pascal. We are simply interested in the news ourselves and prefer to share 
it through Pascal News . We desire to minimize paperwork, because we have 
other work to do. 

American Region (North and South America): Send $6.00 per year to the 
address on the reverse side. International telephone: 1-404-252-2600. 
European Region (Europe, North Africa, Western and Central Asia): Join 
through PUG (UK). Send £4.00 per year to: Pascal Users Group, c/o Computer 
Studies Group, Mathematics Department, The University, Southampton S09 5NH, 
United Kingdom ; or pay by direct transfer into our Post Giro account 
(28 513 4000); International telephone: 44-703-559122 x700. 
Australasian Region (Australia, East Asia - incl. Japan): PUG(AUS). Send 
$A8.00 per year to: Pascal Users Group, c/o Arthur Sale, Department of 
Information Science, University of Tasmania, Box 252C GP0, Hobart, Tasmania 
7001, Australia . International telephone: 61-02-23 0561 x435 

PUG (USA) produces Pascal News and keeps all mailing addresses on a common 
list. Regional representatives collect memberships from their regions as a 
service, and they reprint and distribute Pascal News using a proof copy and 
mailing labels sent from PUG(USA). Persons in the Australasian and European 
Regions must join through their regional representatives. People in other 
places can join through PUG(USA). 

RENEWING? 

Please renew early (before August) and please write us a line or two to tell 
us what you are doing with Pascal, and tell us what you think of PUG and 
Pascal News . Renewing for more than one year saves us time. 

ORDERING BACK ISSUES OR EXTRA ISSUES? 

Our unusual policy of automatically sending all issues of Pascal News to 

anyone who joins within a academic year (July 1 to June 30) means that we 

eliminate many requests for backissues ahead of time, and we don f t have to 

reprint important information in every issue — especially about Pascal 

implementations ! 

Issues 1 .. 8 (January, 1974 - May 1977) are out of print . 

(A few copies of issue 8 remain at PUG (UK) available for £2 each.) 

Issues 9 .. 12 (September, 1977 - June, 1978) are available from PUG (USA) 

all for $10.00 and from PUG(AUS) all for $A10. 

Issues 13 .. 16 are available from PUG (UK) all for £6; from PUG(AUS) all for 

$A10; and from PUG(USA) all for $10.00. 

Extra single copies of new issues (current academic year) are: $3.00 each 

- PUG(USA); £2 each - PUG (UK); and $A3 each - PUG(AUS). 

SENDING MATERIAL FOR PUBLICATION? 

Your experiences with Pascal (teaching and otherwise), ideas, letters, 
opinions, notices, news, articles, conference announcements, reports, 
implementation information, applications, etc. are welcome. Please send 
material single-spaced and in camera-ready (use a dark ribbon and lines 18.5 
cm wide) form. 
All letters will be printed unless they contain a request to the contrary. 
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:ontr ibutors to this issue (#17) were: 

EDITOR Rick Shaw 

Here & There John Eisenberg 

Books & Articles Rich Stevens 

Applications Rich Cichelli, Andy Mickel 

Standards Jim Miner, Tony Addyman 

Implementation Notes Bob Dietrich 

Administration Moe Ford, Kathy Ford, Jennie Sinclair 



APPLICATION FOR LICENSE TO USE VALIDATION SUITE FOR PASCAL 

Name and address of requestor: 

(Company name if requestor is a company) 



Phone Number: 

Name and address to which information should 
be addressed (Write "as above" if the same) 



Signature of requestor: 
Date: 



In making this application, which should be signed by a responsible person in the 
case of a company, the requestor agrees that: 

a) The Validation Suite is recognized as being the copyrighted, proprietary prop- 
erty of R. A. Freak and A.H.J. Sale, and 

b) The requestor will not distribute or otherwise make available machine-readable 
copies of the Validation Suite, modified or unmodified, to any third party 
without written permission of the copyright holders. 

In return, the copyright holders grant full permission to use the programs and doc- 
umentation contained in the Validation Suite for the purpose of compiler validation, 
acceptance tests, benchmarking, preparation of comparative reports, and similar pur- 
poses, and to make available the listings of the results of compilation and execution 
of the programs to third parties in the course of the above activities. In such doc- 
uments, reference shall be made to the original copyright notice and its source. 

y Distribution charge : $50 . 00 

X Make checks payable to ANPA/RI in US dollars drawn on a US bank. 
Remittance must accompany application. 

Source Code Delivery Medium Specification: 

9-track, 800 bpi, NRZI, Odd Parity, 600' Magnetic Tape 

( ) ANSI-Standard 

a) Select character code set: 

( ) ASCII ( ) EBCDIC 

b) Each logical record is an 80 character card image. 
Select block size in logical records per block. 

( ) 40 ( ) 20 ( ) 10 

( ) Special DEC System Alternates: 
( ) RSX-IAS PIP Format 
( ) D0S-RSTS FLX Format 



Mail 


request 


to: 


ANPA/RI 




P.O. 


Box 598 




Easton, Pa. 


18042 


USA 






Attn 


: R.J. C 


ichelli 



Office use only 



Signed 
Date 



Richard J. Cichelli 

On behalf of A.H.J. Sale & R.A. Freak 
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Editor's Contribution 



GETTING STARTED 

Let me start my first editorial by saying, "I can T t believe how hard this job 
is!!" My esteem for Andy Mickel has always been high, but after the last few 
months, it has gone up astronomically! I don't know how one person had all 
the time — there are so many things to do, and I have been lucky enough to have 
alot of help. 

My section editors have been very prompt (for the most part!) and have made 
the job "do-able". And, I might add, PUG has hired some part-time clerical 
help that is out of this world! To round it off, the switch to a commercial 
printer (oh, the luxury of a university print shop) has been quite successful. 
I could not ask for better service. Their prices are close to those we paid 
in the past. 

My thanks 

must go to the membership, who have been so patient with me. This issue 
represents a tremendous learning curve for me (and culture shock!). Things 
will go smoother starting next issue. 

NEXT ISSUE (#18) - SPECIAL!! 

Speaking of next issue, we at PUG are pleased to announce that the next one 
will be completely devoted to the ISO Draft Standard for Pascal. (See Jim 
Miner ! s article this issue for a discussion of this and other items concerning 
standards.) 

We are currently preparing this document for reproduction; it will be out no 
later than one month after this issue (#17). 

ABOUT THIS ISSUE 

WOW!! Is there alot of good stuff in this issue! Pascal has been on 
everyone's tongue lately, so "Here and There" is chock full of "newsy" 
information. We also have a large number of books and articles that have been 
reviewed this quarter, as well as an excellent in-depth review of the text 
Alagic and Arbib by one of our readers. (We could use more contributions such 
as this.) 

The "Articles" section is kicked off by lucid discussion of "Conformant Array 
Parameters" authored by Arthur Sale (who else!). This article is highly 
recommended for review by all readers because of its controversial, proposed 
inclusion into the ISO standard. 

There is no lack of contributions to the "Software Tools" section either. 
Nearly one-quarter of the issue is devoted to publishing programs and 
algorithms. This quarter many checklists are included in the "Implementation 
Notes" section, as well as some contributions to ur new section, "Validation 
Suite Reports". 

A great deal of fine work went into this issue. We hope you like it. 




Here and There With Pascal 
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J. Mack Adams, Comp. Sci Dept. , Box 3CU, New Mexico State University, Las 
Cruces, NM 88001: "We have added an assertional checking capability to UCSD 
Pascal and have developed a debugging system based on assertional checking 
and symbolic execution. A paper on the system will be presented at ACM 
79..." (*79/05/14*) 

Ron Bars tad , P.O. Box 6000, B-118, Phoenix, AZ 85005: "The Pascal on the 
(*USW Louisiana*) L68 (Multics) is only a subset. The L66 version from 
Waterloo is a full blown batch and/or TSS version. (*79/09/14*) 

Dr. Oddur Benediktsson , Science Institute, University of Iceland, Dunhaga 3, 
Reykjavik: "We... are looking for a PASCAL compiler for... our PDP-11 RSX-11M 
system and so far have found only the OMSI product which we find a bit on 
the expensive side at' $1500. We would also rather have the P-code type 
compiler if available. Can you make any suggestions? (*78/l 1/23*) 

Rick Boggs , Nationwide Insurance, One Nationwide Plaza, Columbus, OH 43216: 
"Our problem is one of finding a Pascal implementation which matches our 
operating environment: a large-scale IBM/AMDAHL center running MVS 3.7 
and... both the TS0 and VSPC interactive systems." (*79/10/10*) 

Paul C. Boyd , PPG Industries, Box R, Elwin-Mt. Zion Rd. , Mt. Zion, IL 62549: 

"We are hoping to implement the OMSI PASCAL-1 package on a DEC 

PDP-11/34. . .under RSX-1 1/M. . .to develop process control programs to run on a 

network of DEC LSI-11/23 micros.... I would appreciate hearing from any OMSI 

PASCAL-1 users with experience in digital control applications." 

(*79/09/27*) 

Glenn A. Burklund, 3903 Carolyn Ave., Fairfax, VA 22031: "Have North Star 

(UCSD) Pascal it is miserable. Going Pascal/Z. . .f or scientifc and 

engineering applications. The funct. & proc. are th main features of 
interest. It is virtually aimpossible to implement under North Star 
Pascal. Unless it is practical to implement these calls easily, Pascal will 
wither on the vine." (*79/10/09*) 

John D. Bush , Minnesota Power & Light Co., 30 West Superior St., Duluth, MN 
55802: "I have been trying to get programmers and DP Managers at MP&L 
interested in Pascal. By finding compilers for our Prime and IBM machines, I 
hope to give some of these people a chance to experiment with the language." 
(*79/10/03*) 

Jim Carlson , School of Dentistry, University of the Pacific, 2155 Webster 
St., San Francisco CA 94115: "The School of Dentistry has recently acquired 
an Omsi Pascal Compiler. . .configured to operate under RSX-1 1M and will be 
installed on a PDP-11/34. We plan to use Pascal primarily for 
administrative purposes, but it will also be available for uses in other 
areas." (*79/05/22*) 



M. B. Clausing , 5603 Fisher Dr., Dayton, OH 45424: "If the matter's still at 
issue, I vote not to affiliate with ACM. I see no particular advantage." 
(*79/07/06*) 



John Corliss, Loyola University of Chicago, 6525 N. Sheridan Road, Chicago, 
IL 60026: "Loyola University. . .has acquired the Pascal compiler from the 
University of Manitoba for academic instructional use. . .we are . 
^interested*) in acquiring PASCAL subroutine libraries that we could use in 
our computer science classes." (*79/05/14*) 

Don R. Couch, 5100 Montreal Dr., San Jose, CA 95130: "I am a student in a 
Cogswell College Pascal course, and use Pascal on a PDP-11/10 computer at 
American Microsystems, Inc." (*no date*) 

R. H. Frank, Digital Consulting Corporation, P.O. Box 32505, San Jose, CA 
95152: "Our company has just released a Pascal Compiler (P2 derivative) for 
the popular CP/M microcomputer system." (*79/09/26*) 

Jim Gagne, M.D., Datamed Research, 1433 Roscomare Rd. , Los Angeles, CA 
90024: "Who's your medical applications editor (if any)? I'll do it if vou 
need." (*79/05/30*) y 

Anton L. Gilbert, Information Sciences, U.S. Army White Sands Missile Range, 
NM 88002: "I am a new Pascal users. It will be used in my research 
group... on a PDP-11/70, PDP-11/35, a PDP-11/34 (* all under RSX-1 1M) and a 
PDP-11/15 (RT-11). One of my employees. . .is especially interested in Pascal 
in Image Processing Research." (*79/06/12*) 

Ricardo^O. Giovannone . Box 3606, University Park Branch, Las Cruces, NM 
88003: "I am a graduate student at New Mexico State University. . .using this 
language since fall '78 and I really like it.... At the moment, I am working 
in a project dealing with implementation of an Educational Data Base System 
using Pascal as a host language. ...We hope to finish in this fall. We are 
using UCSD Pascal Version 1.4." (*79/08/20*) 

Mark Gordon, Computer Business Systems, Box 421, Truro, Nova Scotia B2N 5C5- 
"I am using a DEC PDP-11 under RSTS/E". (*79/05/23*) 

Roedy Green , 1478 East 27th Avenue, Vancouver, British Columbia V5N 2W5: 
"I'm loking^after a computer acquisition for the provincial Electric and Gas 
utility. I'm looking forward to using Pascal to implement our records & man 
scheduling system. At present Burroughs 1800, DEC PDP-11/70, Tandem, Univac 
1100, Cyber 170 are all potential winners. I am particularly interested in 
Pascal on these machines." (*79/09/04*) 

David L. Hamby , Combustion Engineering, INc, 1000 Prospect Hill Rd., 
Windsor, CT 06095: "Interests are real time process monitoring. Looking for 
process support software in a machine independent high level language." 
(*79/06/18*) 

M. L. Harper , Oak Ridge National Labs, Bldg. 1505, Rm. 118, Oak Ridge, TN 
37830: "I have pursued your references at JPL regarding a Pascal for ModComp 
minicomputers and the prospects look promising." (*79/06/26*) 

David C. E. Holmes , P.O. Box 1708, Grafton, VA 23692: Teacher of 
micro-computer design, system design, and programming, owns 48K Z80 Altair 
8800, CP/M, UCSD Pascal, and Ithica Intersystem Pascal/Z compiler. 
(*79/10/29*) 

Mike Hughes , P.O. Box 393, Rapid City, SD 57709: "I am currently about three 
fourths of the way there on a business-oriented Pascal compiler for 
second-generation BCD machines. The implementation is for the RCA 301, but 
the problems are similar to the IBM 1401 and 1620, Burroughs B600, etc. I 
would be interested in getting in touch with anyone else having such 
Quixotic interests." (*no date*) 



G. P. Janas , 4447 Buchanan, Warren, MI 48092: "I own an Apple ] [ with two 
disk drives. I have on order, since September, the Apple Language Card and 
am awaiting same." (*79/10/18*) 



Peter T. Jawbsen , Ceremain Microsystems, 759 Glen Canyon Rd. , Santa Cruz, CA 
95060: "I use both UCSD and OMSI Pascal." (*79/09/09*) 

John W. Jensen , Jensen Farms, RR#1 Box 142, Everly, IA 51338: "I have been 
working on computer programs for a complete feedlot management system for 
about 4 years. The programs are written in RPG and run on an IBM System 34 
which... I am losing access to.... I... am wiling to look at something in the 
$10-15000 range not counting sof tware. . . (* here follows a description of 
hardware being considered *) Basic is the mos.t popular language. . .but I m 
not convinced that Basic is the best language to program in. Pascal has 
been called the software superstar. Yet it appears to me to be rather slow 

in being accepted. I have seen very little commerical software available 

(such as accounting packages, etc.)." (*79/10/01*) 

Donald R. Kelley , 2451 Hingham Court, Woodbridge, VA 22192: "Just^getting 
started using Pascal - have been working with assembly and BASIC. 
(*79/10/01*) 

Wallace Kendall , 9002 Dunloggin Rd., Ellicott City, MD 21043: "I have an OSI 
Challenger III and have been trying for some time to get Pascal for it. 
Althought it has a Z80 chip (as well as a 6502 and a 6800) OSI apparently 
used a slightly different implementation, and the version used by most Z80 
computers (I'm told) doesn't run on OSI. HOwever, I'm told that it will soon 
be ready either for the 6502 or the Z80 in OSI." (*79/05/07*) 

Jack Laffe, 320 19th Ave. S. , Minneapolis, MN 55454: "Re: injphing, ^To^T 
imnle^nla'tions : remove NCR 200 implementation that is listed m News #9/10 
p 105. This has been replaced by an NCR 8400 implementation and will be 
available February 1980. I will make more information available at that 
time." (*79/08/07*) 

W. A. Lane, Canadian Tire Corporation, Limited, Box 770, Station K, Toronto, 
ONtario M4P 2V8: "We are a large retailing company in Canada with 
approximately 315 stores country wide. We are presently implementing "point 
of Sale" systems in these stores and are utilizing Datapoint, NCR and Amdahl 
computers. We also have several other machines including IBM system 34' s, 
IV Phase and Basic mini's." (*79/08/22*) 

James H. Lauterbach , Genesys Corporation, 223 Alexander Ave. , Upper 
Montclair, NJ 07043: "Genesys Corporation. .. (*wishes*) to feature 'canned' 
applications programs which are easily customized. . .hence, our development 
system will probably be configured largely with C Basic and Pascal 
capability in mind— especially Pascal. Our quandary, at present, revolves 
arund the. . .relative merits of UCSD Pascal, the Per Brinch Hansen sequential 
version, the Intersys terns Pascal/Z, the Alpha Micro version, the new 6809 
Motorola version, the soon to be released Data General Micro NOva version, 
etc. etc. etc. Can you kindly bring some illumination to us?" (* no date *) 

C. E. Leonard , 14008 S.E. Harrison, Portland, OR 97233: "I presently own an 
Exidy Sorcerer (Z80) with 32K and want to implement Pascal to go with my one 
year of Pascal studies at Portland Community College." (*79/08/31*) 

Jerry LeVan, Eastern Kentucky University, Richmond, KY 40475: "I have 
extended Pascal-S with strings, scalars, graphics, execution profiler and 
many features useful 'in a teaching environment - runs under RSTS on a 
PDP-11/70." (*79/06/ll*) 

Robert C. Luckey , M.D., P.S. , 1110 Gillmore Ave., Richland, WA 99352: "It is 
with distress that I read in the truly excellent issue 13 of your (*Andy's*) 
withdrawal from active lead position. You obviously have that combination 
of talent to co-ordinate a complex development such as that of a new high 
level computer language. None of the alternatives offered to the present 
arrangement at all compares with what we have now." (*79/03/26*) 

Phong Thanh Ly_, 6415 Prospect Terrace, Alexandria, VA 22310: "I am currently 
using Pascal on a PDP-11 and am going to have a Pascal compiler for the 
Honeywell Level-6 very soon." (*no date*) 



Gregory A. Marks, Institute for Social Research, University of Michigan, 
SQR(A), MI 48106: "All I ever hear about UCSD Pascal is the good comments. 
Where can I get the opposite viewpoints; the problem in their extensions and 
implementation." (*79/06/29*) 

Richard R. Martin , 634 Dallas Ave. #21, Grand Prairie, TX 75050: "I am 
running the UCSD Pascal on my Z80 system and am interested in keeping up 
with other implementations. My use for Pascal is in writing a CAI system 
with color graphics (RAMTEK). For a living, I manage a computer store." 
(*79/08/27*) 

M. E. Markovitz, Culp & Tanner, Inc., 585 Manzanita Suite 6, Chico, CA 
95926: "I am trying to build up a Pascal scientific library and would like 
to see if anyone else could lend me a hand. P.S. Does the user's group have 
such a scientific library?" (*79/07/23*) 

Sakari M. Mattila , Lokkalantie 18 B 43, SF-00330 Helsinki 33, Finland: "I am 
a computer scientist at Technical Research Centre of Finland, EDP research 
division. We have University of Minnesota Pascal 6000 release 3 on CDC and 
some other on minis." (*79/07/07*) 

Frank Monaco , 679 Lowell Drive, Marietta, GA 30060: "Keep up the good work." 
(*79/03/09*) 

Jerry Moore , Dunn, Moore & Associates, 2935 E. Broadway, Suite 201, Tuscon, 
AZ 85 716: "We are a systems house in Tucson working primarily with 
Perkin-Elmer (Interdata) and Alpha Microsystems minicomputers. We have a 
project slightly outside our normal sphere of influence, and... for which 
Pascal is most desirable. (*The project is*) a hydrologic model of complex 
irrigation systems for Saudi Arabian Naval base (* which *) must run on an 
IBM 3032 in Saudi Arabia. Development will have to be done on DEC 
system. . .unless I can find some IBM 370 time nearby. I would be very 
appreciative if you would consider my plight briefly and forward any 
suggestions." (*79/09/04*) 

Hal Morris , Prindle and Patrick Architects: planners, 199 S. Fifth St., 
Columbus, OH 43215: "The company... is an architecture firm which has a PDP- 
11/34 running RT-1 1 and TSX. Our applications are Accounting, Word 
Processing, and some statistics and simulation.... My own impression is 
that C and Pascal are quite complementary, C being a better systems 
language, and Pascal being better for many, or even most applications." 
(*79/10/17*) 

Gregory L. Nelson , Apt. 31, 2280 California St., Mountain View, CA 94040: 
"Have implemented Swedish Pascal V5 and NBS Pascal VI. 4d (a preliminary 
version) under RSX-11M V3.1 on a PDP-11/70 system. Both Pascals lack 
operating system linkages sufficient to consider them for systems 
implementation." (*79/03/12*) 

Neil Overton , Computer Systems and Services, Inc., Box 31407, Dallas, TX 
75231: "I wanted an accounting package in Pascal or BASIC to be converted to 
run on a TI 990/2 for a large non-chain restaurant." (*79/09/05*) 

Craig Payne , Enertec, 19 Jenkins Ave., Lansdale, PA 19446: "We are actively 
using Concurrent Pascal to write real time programs for the Z80. The 
language has been extended to allow the writing of device drivers directly 
in C.P.; the interpreter/kernel knows nothing about I/O." (*79/06/05*) 

Raymond E. Penley , 3578F Kelly Circle, Boiling AFB, DC 20336: "Just 
purchased Pascal/Z from Ithaca Intersystems. This is a Z80 compiler that 
makes assembly code directly from the Pascal source. Will let you know more 
when I get it running. I don't have enough memory right now." (*79/09/24*) 



Martin M. Peritsky , Bendix Corporation, P.O. Drawer 831, Lewisburg, WV 
24901: "I am available for membership on standardization committees, etc. 
am a member of IEEE and ISA. One of my specialties is compiler design." 
(*79/10/30*) 



Stephen A. Pit'ts , 305 Jarman Dr., Midwest City, OK 73110: "I have ordered 
Apple Computer's Pascal system for my Apple ] [." (*79/08/24*) 

Stephen M. Piatt , 4060 Irving St., Philadelphia, PA 19104: "In my work (CS 
grad student U. of P.) people are starting to prefer Pascal to FORTRAN for 
reasons of portability (! ) and ease of use. From my own view, it's a choice 
of hours debugging 100 lines of FORTRAN or not having to debug 700-1000 
lines of Pascal... you get the idea. Keep up the good work." (*79/09/13*) 

Michael S. Plesher, RDI Box 258, Hoewell, NJ 08525: "I am currently using 
the AAEC compiler on an IBM 370/168 (RCA, Cherry Hill NJ). They also have a 
Pascal P4 compiler." (*79/08/05*) 

Hardy J. Pottinger , EE Dept. , Univ. of Missouri Rolla, Rolla, MO 65401: "We 
are using University of Lancaster's implementation for Nova from Gamma Tech 
under RDOS and DOS. Like it a lot. We will be experimenting with 
microcomputer versions and concurrent Pascal during coming year." 
(*79/08/01*) 

Fred W. Powell , P.O. Box 2543, Staunton, VA 22401: "I have been working 
primarily on a TI 990/10 computer which has a TI supported Pascal compiler. 
I expect to soon be using a TI 990/5 system which does not currently support 
the Pascal compiler. if TI does not change that problem soon, I intend to 
put the Pascal P compiler on that system. Thanks for your help and for the 
good job you are doing with PUG." (*79/10/08*) John Purvis , Sperry Univac 
Computer Systems, 55 City Centre Dr., Missisaugua, Ontario L5B 1M4: "I am a 
software instructor with Sperry Univac in Toronto. Our Mini Computer 
Operation is becoming involved with Pascal, so I am very interested in 
finding out what is happening with a Pascal user group." (*79/08/24*) 

Frederick A. Putnam , Joseph R. Mares Asst. Prof. , Dept. of Chemical 
Engineering, Massachusetts Institute of Technology, Cambrdige, MA 02139: 
"Here in the Chemical Engineering Department, we have a Data General Eclipse 
running (among other things) Gamma Technology's Pascal." (*79/10/17*) 

Holly Robinson , Winthrop Publishers, Inc., 17 Dunster St., Cambridge, MA 
02138: "We are about to publish two titles which will be of considerable 
interest to your PASCAL NEWS readership: PROGRAMMING FOR POETS : A GENTLE 
INTRODUCTION USING PASCAL , by Conway & Archer; and A PRIMER ON PASCAL by the 
same authors." (*79/10/03*) 

Armando R. Rodriguez , P.O. Box 5771, Stanford, CA 94305: "I am in charge of 
the compilers for Pascal at LOTS, SAIL, GSB, SUMEX, and SCORE at Stanford, 
all of them DEC-10 or DEC-20. I am preparing a note on our improved version 
of the Hamburg compiler for DEC-10 and DEC-20." (*79/06/21*) 

Wayne Rosing , Digital Equipment Corp., TW-C03, 1925 Andover St., Tewksbury 
MA 01876: "I was a 12/15/78 lost soul. I figured for $4/year you had gone 
out of business or you folks had been eaten by a FORTRAN compiler. (I'm on 
UCSD now but want to get a 32-bit Zurich version up on a 68000, demand 
paging off an 8 inch Winchester hard disk.)" (*79/08/20*) 

Louis V. Ruffino, Federal Systems Division, IBM, 18100 Frederick Pike, 
Gaithersburg MD 20854: "Your pubs are excellent, but keep up the great 
work. 
I look forward to PUG just like BYTE!" (*79/07/09*) 

Carl Sandin , 314 Shadow Creek Dr., Seabrook, TX 77586: "I have a SOL-20, 
with North Star disks and Diablo printer. I'm trying to get started in 
North Star Pascal." (*79/08/06*) 



Robert H. Scheer , CDP, Sheridan Oaks Cybernetics, 1915 Larkdale Dr., 
Glenview, IL 60025: "I have' had some limited experience with Pascal on an 
Alpha Micro system and expect to start a project on a North Star Horizon 
microcomputer system before the year is over. I am also an instructor in 
computer science at Northwestern University's Division of Continuing 
Education in Chicago. I am investigating the possiblity of using Pascal as 
a means of teaching structured programming techniques." (*07/07/09*) 

R. C. Shaw , The Grange, Spring Brank New Mills, Nr Stockport, Cheshire, SK12 
4BH: "I would be interested in information on Pascal implementations on 
either Argus 700 or Modular One machines." (*07/09/13*) 

Thomas W. Sidle , Technical Staff, Scientific Calculations, Inc., 4245-B 
Capitola, CA 95010: "We are interested in bringing up Pascal on VAX11/780, 
Prime 400 (and larger), and IBM 370/148 (and larger) computers." 
(*07/07/24*) 

Connie Jo Sillin , Kansas City Southern Industries, Inc. 114 W. 11th St., 
Kansas City, MO 64105: "We at KCSI are interested in the Pascal programming 
language and the compiler for Pascal. We now have the IBM 370/158 and 3032 
(0S-VS2) soon to be 3033 (MVS). 

T. R. Simons on , G.M. Simonson & T.R. Simonson Consulting Engineers, 612 
Howard Street, San Francisco, CA 94105: "I realize that PUG may have simply 
collapsed. I certainly hope not, for I have thoroughly enjoyed the 
contact. I believe you stated that some cross compilers exist for creating 
8080 or Z80 machine code. If you know of one for CDC machines I would 
appreciate your jotting down the source." (*79/10/12*) 

Lee L. C. Sorenson , 10226 Victoria Ave, Whittier, CA 90604: "I do not yet 
have a large enough system for Pascal, but I hope to learn from your group 
and to implement it in my system, some day." (*79/06/07*) 

T. J. Sullivan , 712 Rand Ave., Oakland, CA 94610: "I work with BART (*Bay 
Area Rapid Transit*) and am a neophyte to Pascal but am highly interested in 
all aspects of the language; particularly interested in programming for real 
time process control." (*79/O6/07*) 

Kevin Talbot , 3029 127th Place S.E. , Bellevue, WA 98005: "The system I use 
is an HP3000 (Pascal P/3000 by Fraley, et. al.)" (*no date*) 

Ron Tenny , President, G.W. Tenny Co. Inc., 3721 Scottsville Rd. , Box A, 
Scottsville, NY 14546: "We are currently using a DEC 11/34 with 256KB 
memory, eight terminals, two printers, and dual 20MB drives in a business 
application environment. We want to implement Pascal under RSTS/E (CTS-500) 
and are looking for a good DBMS package to go with the Pascal code." 



William W. Tunnicliffe , Bobst Graphic, INc, P.O. Box 462, Bohemia, 
11716: "Thanks, volunteers!" (*79/08/20*) 
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Rex M. Venator , Major USA, 12451 Skipper Circle, Woodbridge, VA 22192: 
"While working on my Masters at Georgia Tech I became a Pascal 'fanatic' and 
since then my enthusiasm has not diminished. I attempt to follow all aspets 
of the language from the standardization efforts to Pascal's- first 
descendant ADA in DOD. I would most certainly like to join your group and 
provide what assistance I can from an unofficial DOD perspective." 
(*79/05/16*) 

Dick Wattson, 10 Dutton St. S. , Manchester, NH 03104: "I surely would 
appreciate info on PDP-11 compilers (RT-1 1 compatible)." (*79/10/31*) 



Anna Watson , 3705 Delwood Drive, Panama City, FL 32407: "Don't be 
discouraged, Andy. You're putting out a really interesting publication, 
expect to use it as a reference tool later." (*79/08/12*) 



Sydney S. Weinstein, CDP, CCP, 170 Centennial Road, Warminster, PA 18974: 
"I am now working for Fischer and Porter Company, and am developing data 
communications software for local networks for them. We use C as our main 
development language, but are also looking at Pascal especially as it 
develops for the PDP-11 and 8086 computers. Pascal is the basis of our new 
'experimental' process control language." (*79/08/19*) 

Tom Westhoff , Willmark A.V.T.I., Box 1097, Willmar, MN 56201: "Are there any 
Pascal implementations for Ohio Scientific Challenger II disk systems?" 
(*79/09/07*) 

Rodney E. Willard , M.D., Loma Linda Medical Center Clinical Laboratory, Loma 
Linda, CA 92350: "I am trying to get a Z80 UCSD-CP/M system together and 
running." (*no date*) 

R. S. Wood , 260 Trafalgar Lane, Aiken, SC 29801: "I'm a research analyst 
working for the DuPont Company at the Savannah River Laboratory. My 
interests in Pascal are both personal i.e., on a home micro and 
professional. The company is looking into the possiblity of using a Pascal 
based 'black-box' between our big main frames and any arbitrary 
microcomputer to make the micros look like all the other IBM-TSO terminals 
in the shop." (*79/07/03*) 

Max Wunderlich , c/o Textronix, Inc., P.O. Box 500, Beaverton, OR 97077: 
"Both of us (*Max Wunderlich & Steve Jumonville*) are software engineers for 
Tektronix, Inc. We are presently using OMSI Pascal for production testing 
purposes on an LSI-11/2 with RT-11." (*no date*) 

Richard Yensen, Ph.D., clinical Psychologist, 2403 Talbot Road, Baltimore, 
MD 21216: "I am running UCSD Pascal version 1.5 on a Heathkit H-l 1 Computer 
with 32K words of 16 bit memory. The computer is a 16 bit machine." 
(*79/07/01*) 



Fred Zeise , Data Systems Design, 3130 Coronado Drive, Santa Clara CA: 
are using ESI/OMSI Pascal and will be getting UCSD Pascal 1.5 soon." 
(*79/05/07*) 
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P ASCAL IN THE NEWS 
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JOBS: 

(* Note-these listings are intended primarily to show that there are indeed 
openings for Pascal programmers "out there". By the time you see these 
listings, the jobs may well be filled. *) 

Control Data Corporation, Communications Systems Division, 3285 E. Carpenter 
Avenue, P.O. Box 4380-P, Anaheim, CA 92803: "Professional openings exist in 
the areas of data communications netowrk, message switching and front-end 
systems. Experienced candidates should be familiar in any of the 
following: Assembly /Pascal/Algol languages, Microprocessors, Real Time 
Systems, Communications protocols, test procedure development, test tool 
development." Contact Jess Holguin. (*Computerworld 79/09/24*) 

Hewlett-Packard, West 120 Century Road, Paramus, NJ 07652: "We have 
opportunities both in Commercial and Scientific areas. Scientific 
experience is desired using FORTRAN, Assembler, BASIC, Pascal, data base, 
data communications with real-time operating systems. (*79/10/12*) 



V.P. Personnel SS160, New York Times: "Minimum of 1 year experience. 
Programming experience with Pascal, PLM, Pll, ALGOL, or FORTRAN" V.P. 
Personnel SS160 Times (*79/10/28*) 

Perkin-Elmer Corporation, Main Avenue, NOrwalk, CT 06856: Looking for a 
micro-computer programmer whose responsibilities include "developing high 
level language (PL/1 , Pascal) techniques to improve software development for 
micro-computers. (*79/10/28*) 



MANUFACTURERS' ADVERTISEMENTS: 

Apple Computer Co., 10260 Bandley Drive, Cupertino, CA 95014: Various 
advertisements for their version of UCSD Pascal 

Columbia Data Products, Inc, 9050 Red Branch Road, Columbia, MD 21045: 
Advertising "a unique family of computer systems, the Commander series" 
which will run Pascal under CP/M. (* Computer Design, October 1979*) 

Enertec, a company in Pennsylvania, has sent a flyer about their version of 
concurrent Pascal, which runs on the HP3000, and has an interpreter/kernel 
for a Z-80 Micro-computer. P-code for a given program is "about one-third 
the size of the P-code from Brinch-Hansen's concurrent Pascal compiler." On 
the Z-80, "execution speed at 4MHz is fast enough to handle 1200 baud 
terminals with all I/O to the IN, OUT level written in Concurrent Pascal. 
P-codes execute in 20 microseconds (push constant) to 500 microseconds 
(divide, context switch) 

Pertec Computer Corp, Chatsworth, CA advertises a "Pascal Blaiser software 
development system, intended for systems and real-time applications 
programming," with 64K RAM, 1 megabyte of mass storage. The CPU directly 
executes Pascal; price is $5995 in single-unit quantities. (*Mini-Micro 
Systems October 1979*) 

Rational Data Systems, 245 W 55th St., New York, NY 10019: has provided a 
Pascal that is "compatible with the entire (*Data General*) line - from 
Eclipse to microNova. All versions are source compatible and each can 
cross-compile for any of the other systems. The AOS version is priced at 
$3500." (*Computer Design, October 1979*) 

Southwest Technical Products Corp., 219 W. Rhapsody, San Antonio, TX 78216 
advertises the S/09 with MC6809 processor. "Both multiuser and 
multitasking/multiuser operating systems are available for the S/09. BASIC, 
Pascal, and an Assembler are immediately available." Cost with 128K bytes 
of RAM is $2995. 

Sperry Univac Minicomputer Operations, 2722 Michelson Dr., Irvine, CA 92713 
has various advertisements for the Structured Programming System (SPS) 
running under their SUMMIT operating system which supports a Pascal 
compiler, debugger, program formatter, and concordance program. SPS also 
includes a text editor and document formatter. 

Stirling/Bekdorf , 4407 Parkwood, San Antonio, TX 78218, advertises 
combination coding and CRT layout sheets to "speed software development and 
documentation for Pascal programmers". Two pads of 50 cost $26.85 plus 
$3.25 for handling. 

Texas Instruments: Various advertisements for the DS990 Model which runs 
Pascal on a system that stores "up to 4,600,000 characters using 
double-sided, double-density diskette storage". Also advertisements in 
various places for their Microprocessor Pascal System with source editor, 
compiler, host debugger, configurator, native-code generator, and run-time 
support. 



Three Rivers Computer Corp., 160 N. Craig St., Pittsburgh, PA. 15213: has a 
stand-alone system that can take up to 1 Megabyte of RAM, with interactive 
graphics (1024 lines on a 15-inch screen), and a speech output module. Mass 
storage is provided by 12 Megabyte Winchester disk drive with a 24 Megabyte 
disk option. "The unit contains a 16-bit processor that operates with 
P-Code, a high-level instruction language based on Pascal. The processor 
can reportedly execute in excess of one million P-Codes per second. The 
system's memory has a 32-bit segmented virtual addressing mechanism," and 
has 4K bytes of writable microstore as an option. (*Computerworld, 
79/10/22*) 



NEWSLETTERS & ARTICLES: 



David A. Mundie has an article on the relative merits of Pascal vs. BASIC in 
Recreational Computing, Sept-Oct 1979. It concludes with "Most Pascal 
lovers are deeply committed to portability and standardization. It is not 
our fault that BASIC dialects have proliferated so wildly that there exists 
no standard BASIC to compare with Pascal." 

Arthur Sale passes on a note from Computing, 1 November 19 79, which mentions 

that the European Space Agency (ESA) will be using concurrent Pascal "to 

program ESA's latest venture into the simulation of satellite subsystems, 
the Multiple Processor Reconf igurable Simulator." 

The Big Byte (University of Calgary) notes in its September 1979 issue that 
"the development of a Pascal compiler under Multics is near completion." 

Early Warning Newsletter (University of Nebraska Computer Network) has a 
"new release of Stanford Pascal. This version is a considerable improvement 
over previous versions. For the most part, changes to the system are 
enhancements and will not affect Pascal programs that ran under the previous 
version." A change has been made to nested comments, giving a compiler 
option to make constructs such as (* x:=y (* comment *) *) legal or produce 
an error as the user desires. (* 79/09/13*) 

Log On (Massey University Computer Centre), notes that "We are to implement 
a Pascal compiler" for a newly-acquired IBM Series /l minicomputer. In usage 
statistics for the B6700, Pascal comes in second place with 10% of usage 
(981 accesses) during June 1979. (*July 1979*) 

ICSA Newsletter (Rice University, Houston TX), tells "Pascal users don't 
despair. Although Pascal is currently not available at ICSA, we hope to 
remedy the situation soon. Plans are underway to install Pascal 8000 this 
fall." (*79/09/17*) 
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BOOKS ABOUT PASCAL 

Alagic, S. and Arbib, M. S. , The Design of Well- structured and Correct Programs, 
Springer-Verlag, 1978, 292 pages. 

Bowles, K. L. , Microcomputer Problem Solving Using Pascal, Springer-Verlag, 1977, 
563 pages. 

Brinch Hansen, P., The Architecture of Concurrent Programs 3 Prentice-Hall, 1977. 

Coleman, D. , A Structured Programming Approach to Data, MacMillan Press, 1978, 
222 pages. 

Conway, R. W. , Gries, D. and Zimmerman, E. C. , A Primer on Pascal, Winthrop 
Publishers Inc., 1976, 433 pages. 

Findlay, B. and Watt, D. , PASCAL: An Introduction to Methodical Programming, 
Computer Science Press (UK Edition by Pitman International) 1978. 

Grogono, P., Programming in Pascal, Addison-Wesley, 1978, 359 pages. Note: 

Those persons using the first printing of this text may obtain a list of 
corrections from: Barry Cornelius, Dept. of Computer Studies, University 
of Hull, Hull, HU6 7RX, England. 

Hartmann, A. C. , A Concurrent Pascal Compiler for Minicomputers, Sprinter-Verlag 
Lecture Notes in Computer Science, No. 50, 1977. 

Jensen, K. and Wirth, N. , Pascal User Manual and Report, Springer-Verlag Lecture 
Notes in Computer Science, No. 18, 2nd Edition, 1976, 167 pages. 

Kieburtz, R. B. , Structured Programming and Problem- Solving with Pascal, Prentice- 
Hall Inc., 1978, 365 pages. 

Rohl, J. s. and Barrett, H. J., Programming via Pascal, Cambridge University Press, 
in press. 

Schneider, G. M. , Weingart, S. W. , and Perlman, D. M. , An Introduction to Program- 
ming and Problem Solving with Pascal, Wiley and Sons, 1978, 394 pages. 

Webster, C. A. G. , Introduction to Pascal, Heyden, 1976, 129 pages. 

Welsh, J. and Elder, J., Introduction to Pascal, Prentice-Hall Inc., in press. 

Wilson, I. R. and Addyman, A. M. , A Practical Introduction to Pascal, Springer- 
Verlag, 1978, 148 pages. 

Wirth, N. , Systematic Programming: An Introduction, Prentice-Hall, 1973, 169 
pages. 

Wirth, N. , Algorithms + Data Structures = Programs, Prentice-Hall, 1976, 366 
pages. 



Alagic, S.; Arbib, ft. A. "The Design of Welt-Structured and 
Correct Programs," Sp r i nge r- Ve r I ay , New York, 197b. 

The major goal of this book is to present the tech- 
niques of top-oown program design ana verification of 
program correctness hand-in-hand. It thus aims to give 
readers a n e * way of looking at algorithms and their 
oesign, synthesizing ten years of research in the 
process. It provides many examples of program and 
proof development with the aid of a formal and informal 
treatment of Hoare's method of invariants.... 



The secondary goal of this book is to teach the 
how to use the programming language Pascal.... 
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From the Preface 



This reviewer is a Pascal production programmer and this review 
is presented in light of that background. while many production 
programmers, not familiar with the Pascal language, may find this 
book to be somewhat difficult at first reading, it is well worth 
the trouole for the insights that it provides. The production 
programmer, considering the purchase of this book, should have a 
well read copy of Jensen ano wirth L 1 3 handy. This book's advan- 
tage is tnat it can raise the programming abilities of its care- 
ful readers. The chapters and the topics chosen for inclusion 
are : 



Chapter 



Top i c 



1 Introducing Top-Down Design 

I Basic Compositions of Actions and Their Proof Rules 

5 Data Types 

A Developing Programs with Proofs of Correctness 

5 Procedures ano Functions 

6 Recursion 

7 Programming with and without Gotos 

Chapter 2 contains an excellent introduction to logical formulas; 
Chapter 3 contains an excellent primer on set theory (expanded 
later in Chapter 4). A bibliography, glossary and subject index 
are included as are two appendices: the syntax of Pascal and a 
complete renumeration of Pascal statement Proof Rules. 
Typography is clean and uncluttered with extremely few typograph- 
ical errors. 



I have only two complaints regarding this book. The first, an 
annoyance, is the excessive use of reference numoers appended to 
examples. The authors also begin reference renumbering at the 
section level rather than at the chapter level. This causes 
unnecessary difficulties to the reader who, ignoring the section 
number, provided at the top of the odd-numbered pages, thumbs 
back to find a referenced example (in one case, the reference is 



to an example in a preceding section, therefore requiring a tit- 
tle detective work to determine exactly wnich example should be 
reviewed!) 1 have founo myself completely baffled by an 
'obviously erroneous' backward reference, only to realize, after 
some consternation, that I had passed back into an earlier 
sect ion ! 

The secona, and perhaps more significant, complaint deals with 
the formatting of ano symbols used in Pascal program examples. 
The indentation scheme is inconsistent. Thus, on page 89, we 
f i no : 



■ hi le 



eof(f) do 

££212 s := s H 

get (f) 
end 



while on the very next page (90) , we find 



tor i : - 1 to numstud go 
begin gr := grade Ci,j3 ; 



11 or j^Q then totgrade := totgrage ♦ gr 
else numgrades := num grades - 1 



In the first example, it is clear that the compound statement is 
within the scope, and therefore control, of the while; in the se£. 
^rond it is not at all apparent that the compound statement is 
under the control of the for. Although this inconsistency may be 
a symptom of a 'gremlin typesetter', it should be corrected in 
future editions. A less disconcerting problem with the type- 
setting of Pascal programs is the use of the non-Pascal symbols 
*A'» 'V '♦ "*^" ana '^' . Since they are not a part of the 
language, they should be replaced oy ano, or, not ano '<>', 
respectively, in alt program fragments (they are acceptable with- 
in the proof comments, since they have a logical meaning). 

This text has been used in at least one graduate level course and 
so contains material of interest to the more erudite Pascal 
programmer. Even though the going may be rough at times, I 
stongly recommend tnis boox to anyone seriously interested in 
programming languages, and especially to Pascal programmers. 



G. Gustafson, San Diego CA 
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UCSD Wo rkshop Proceedings 

The Proceedings of the July 19 78 UCSD Workshop on Pascal Extensions 
(see Pascal News #13, pages 12.. 15) are now available for $25 from: 

Institute for Information Systems 

Mail Code C-021 

University of California, San Diego 

La Jolla, CA 93093 

USA 

Payment must accompany all orders. 

| Several persons involved with the Workshop expressed to me 
their unhappiness with the Proceedings. Because of this, 
I asked Ruth biggins, who served on the Editorial Board, to 
provide some background information. Ruth graciously agreed 
to do so, and the following note is the result."^ 

-Jim Miner 
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Comments on the Proceedings of the UCSD Workshop on System Programming Extensions 
to the Pascal language. 



The Proceedings of the UCSD Workshop on System Programming Extensions to the 
Pascal Language are now available. I would like to provide some information 
for the benefit of those who did not attend the workshop but will obtain a 
copy of the proceedings. 

Near the end of the second week of the Workshop, it became clear that we would 
not be able to approve the wording of a final document within the time frame 
of the Workshop. And yet, since the proceedings would be purported to 
represent consensus of about 50 industry representatives, it was important 
that they be accurate. To that end, the Workshop participants appointed an 
Editorial Board whose function was to compile a draft of the proceedings for 
UCSD to distribute to Workshop attendees for comment with respect to accuracy, 
review those comments, attempt to edit the draft to reflect the comments and 
prepare a final version. Preparation and distribution of copies was provided 
by the Information Sciences Institute, UCSD. 



The Editorial Board met in August, 1978, to prepare the draft. It was 
distributed to Workshop members with the phrase "Not for distribution" on each 
page. The comment period was to last until the end of October. The next 
date when most of the Editorial Board could meet was January 11, 1979. At 
that time, we went through each section of the proceedings and tried to 
incorporate comments as fairly as possible. We then wrote instructions to 
Gillian Ackland, the UCSD person who was doing the actual editing and 
distribution of the document. We also wrote a cover letter to accompany the 
proceedings. Copies of both of these are enclosed. 

In late April or early May, I received a phone call from Gillian. She said she 
had had a wery busy winter quarter and had not been able to do anything at all 
on the proceedings. However, in the Spring, she had gone on with the 
work but had a few questions. Instructions 1 through 5 (see enclosed) were OK, 
but why didn't the Editorial Board members want their names included except 
in the Workshop attendees list? I told her that we had discussed this at length 
and agreed that we did not want our names to lend credibility or be 
misconstrued as endorsement of the poor technical quality of the document. 

She had another question regarding Section G (Proposed Experiments) on the 
subsection on Type Secure External Compilation. This section had sparked 
several, carefully written, long letters disputing the accuracy of what 
claimed to be a representation of the part on which there had been agreement. 
The Board could find no way to treat these fairly except to instruct Gillian 
to include the letters also in that section. For some reason, Ken Bowles and 
Terry Miller did not want to do that. Instead, they left the section as it was 
in the first draft and added, as an editorial comment, the sentence "The 
accuracy of this representation has been disputed." She asked me if that was 
all right. I said that the Board had considered that approach but felt it 
would be educationally important to include all of the disagreement to show 
how pervasive the dispute was. Anything less would be misleading and, therefore, 
unfair to the workshop participants. Gillian suggested that they rewrite the 
section, incorporating the comments as best they could. I told her that the 
rewritten section would have to be approved by, at least, those who had 
disputed the first version. It seemed to me that the simplest, fairest, and 
most professionally honest way to handle it was to make the whole technical 
controversy available to the readers. In addition, it would help to demonstrate 
how complicated the issue of external compilation really is. 

When one receives a copy of the proceedings one can see that the cover letter 
is not included; the words "not for distribution" do not appear as per 
the Board's instructions; and the subsection on Type Secure External Compilation 
does not include any of the related technical controversy. Finally, a final 
copy was not sent to the Editorial Board Chairman as requested in 8 (see enclosed). 
I was told that the matter was handled in such a way in the interest of time, 
that the whole thing had dragged on far too long and any further delay was 
not iustified compared to the desirability of getting it distributed. It is 
not clear to me how the Board's instructions could have added noticeable 
delay. 



Sincerely, 



Ruth M. Higgins 
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Dear Gillian: 



Many thanks for getting your new version of Sections B thru F 
to us. There was some concern about how certain comments had been 
handled. Having the updated version allowed us to check. 

We have decided that, on the basis of responses from reviewers, 
the proceedings do not merit publication. However, the Workshop 
participants deserve an accurate report. Therefore, enclosed are the 
required corrections. 

Regarding overall format, 

1. Replace Section A with the enclosed; 

2. Edit Sections B through G as shown. Although you did not 
send us your copy of G, the Board edited a copy from 

the first draft to our complete satisfaction; 

3. Delete Section H, Section I, and Appendix X; 

4. Insert page numbers in the Table of Contents; 

5. The list of participants should be in alphabetical order 
by name of individual accompanied by affiliation, omitting 
addresses and phone numbers. 

The members of the Editorial Board do not wish to have their 
names appear anywhere except among those of Workshop 
participants. 

7. Since the Board feels that these proceedings do not merit 
wide distribution [even though persons requesting individual 
copies should receive them at cost), the phrase NOT FOR 
DISTRIBUTION will remain on each page. 

8. Before printing, mail a final copy to Bruce Ravenel . He will 
ascertain that editing instructions were understood correctly. 

Thank you again for your tremendous efforts. We appreciate the 
work you have done so far. Good Luck in this semester! 

The Editorial Board 
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To: The Workshop Participants 

From: The Editorial Board 

Subject: The Enclosed Proceedings 

Date: January 11, 1979 



This is the final version of the Proceedings to the UCSD Workshop 
on System Programming Extensions to the Pascal language. 

In light of review responses received, the Editorial Board 
has decided that the quality of the contents of this document merits 
distribution to the Workshop participants only. It does not warrant 
publication. However, as prescribed in the general resolutions (Sec- 
tion B), copies will be sent to a few others and will be available 
at reproduction and mailing costs to any who request individual copies. 
Recipients of this document are requested to restrain from distributing 
it further. 

The production of these Proceedings reflect the combined 
efforts of many people. In particular, Gillian Ackland has performed 
an outstanding, Herculean effort of document preparation and distribution 
under the guidance of Terry Miller and Ken Bowles. We wish to thank 
them on behalf of the Workshop participants. 



A Report on Pascal Activities at the 
San Diego 1979 Fall DECUS U.S. Symposium 



Bill Heidebrecht 

TRW DSSG 

One Space Park 

Redondo Beach, CA 90278 



John Barr gave a presentation of his work on implementing NBS Pascal on LSI 11 's 
running RT-11 . The compiler is completely selfsupporting now on such systems, and can 
compile itself on a 28K word machine using the RT-11 SJ monitor. It takes approximately 
10 minutes to compile the compiler on an LSI-11 using floppy disks (about 700 lines/minute). 
The compiler is not yet a full implementation of Standard Pascal, but we (the Pascal SI6) 
are working on it. 

William Donner and James Forster of TMI Systems gave interesting presentations on 
the implementation of a financial message switch for EFT using a Pascal Multi-Process 
Subsystem (PMPS-11), which they also implemented. They added concurrency facilities 
(processes, monitors and semaphores) to OMSI Pascal strictly by adding to the runtime, 
without extending the language. Fed up with MACRO, FORTRAN and RATFOR, they considered 
using C, PL/I and Pascal as their implementation language. They chose Pascal for its 
reliability, efficiency and good structure. 99% of their system is written in Pascal. 

Isaac Nassi of Digital Equipment gave two overview presentations on Ada, which 
were very well attended. The audience seemed somewhat overwhelmed by the complexity of 
the language. 

During the Pascal SIG Business Meeting a variety of topics was discussed. For 
example, Leslie Klein gave an update on DEC'S VAX Pascal compiler. The compiler has under- 
gone field testing since June 79 at 15 sites, and should be ready for shipment to customers 
yery soon (approx. December 79). Although it is not a highly optimizing compiler, the 
test sites were largely enthusiastic about it. One of the test site users reported 
moving a large program from CDC Pascal to the VAX with only 3 changes to the program 
required. DEC should start receiving some user feedback on the compiler by the next DECUS 
Symposium. 

Reid Brown of Digital spoke about the positive influence the Pascal SIG has had 
on Digital with respect to Pascal. 

Roy Touzeau ( Pascal SIG Newsletter Editor) and John Barr also spoke on a number 
of subjects concerning the SIG. Due to DECUS 's new funding structure, each SIG may 
soon have to charge a small annual subscription fee for its newsletter. 

I spoke briefly about the status of the DECUS Pascal SIG library. The Fall 79 
Pascal SIG library contains two versions of Seved Torstendahl 's "Swedish" Pascal: 
version 6, which contains some new symbolic debugging facilities, and the version 
modified by Gerry Pell etier to enable it to compile itself on a PDP11 . There are also 
versions of NBS Pascal for RSX, RSTS and RT-11 systems, as well as a number of other 
utilities. PN readers who are interested in the Pascal SIG library should consult 
recent editions of the DECUS Pascal SIG Newsletter for more details. 

The next DECUS U.S. Symposium will be held in Chicago on April 22-25, 1980, and 
will again feature a number of interesting Pascal sessions. 



The 1979 Fall Digital Equipment Computer Users Society (DECUS) U.S. Symposium was 
held in San Diego, California on December 10-13. Approximately 600 of the 2500 people 
who preregistered indicated an interest in Pascal. The DECUS Pascal SIG, chaired by 
Dr. John R. Barr of the University of Montana, has now grown to over 2000 members. 

In the Pascal Implementation Workshop, John Barr, Brian Nelson and I spoke briefly 
about the implementation of NBS Pascal under RSX, RT-11, RSTS and VAX/VMS systems. 
Gerry Pelletier of Transport Canada spoke about his work in implementing a self compiling 
version of Torstendahl l s "Swedish" Pascal (V5.3) under RSX-11M. 

In the Pascal Standards Report, Leslie Klein (DEC) and Barry Smith (Oregon Software) 
reported on the current status of the ISO draft standard and progress within the X3J9- 
IEEE Joint Pascal Committee. Barry gave a detailed discussion on conformant array para- 
meters and answered a number of good questions from the audience. The quality of questions 
asked showed the increasing level of sophistication of Pascal users in the DEC world. 
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REPORT ON ADA 

Ada is a programming language being produced by the 
U.S. Department of Defense in cooperation with several foreign 
and international organizations. The project has spanned five 
years and is unique for its openness in all phases and the 
resultant international contributions. 

The first phase was an evolution of requirements from 
the users by an itterative process which produced five versions, 
increasingly refined. These documents were widly circulated 
and major input was received from individuals outside the U.S., 
from the International Purdue Workshop such especially its LTPL-E 
committee, and from experts of SC 5/WG 1 . Major support has been 
contributed by the CEC and by the goverments of the U.K. and 
Germany. We believe that this requirements phase was very valuable 
in settling many of the questions that normally arise much later 
in the development process, when they are much more difficult to 
deal with. It might be said that, in the best procedure for 
major projects, we are proceeding thorough definitive requirements, 
followed by firm design, before coding. 

After evaluation of several dozen existing languages 
against these requirements, a new design was initiated. On the 
basis of an international request for proposal , four contractors 
were chosen to produce competive prototypes . [All started from 



Pascal, although there is no intent that the resulting language 
be closely related to Pascal, sin c e their requirements were much 
dif ferent . I The initial designs from these four contractors were 



reviewed by several hundred experts worldwide and a decision was 
made to continue refinement of two of the designs. A year later, 
these two designs were reviewed, again with international partici- 
pation. The single design selected was that produced by Cii 
Honeywell-Bull. That design, and a document giving rationale for 
design decisions, are contained in N-499 and have been distributed 
as the June 1979 issue of SIGPLAN Notices. A preface from the 
Secretary of Defense requests international public comment. 



2) 

For any that do no have this document, a microfiche is available 

this meeting. 

Ada is a modern powerful computer programming language. 
It has real-time features and has been under consideration by WG 
for that reason. It is however targeted to a much wider audience. 



Ada promotes modularity for the production of large 
systems, strong data typing for reliable, even provable, programming, 
etc. A rigorous definition will allow .control of the language 
to make possible wide portability. It is our intent that there 
be no subset or superset compilers and that a validation facility 
be used to assure compliance. 

Our economic analyses show that even more benefit may 
be attributed to the commonality resulting from exactly compatible 
systems than that would be attributed to the technical improvements 
postulated from introduction of Ada. 

Even greater benefits may accrue from the wide availabi- 
lity if tools a development environment, debugging systems, appli- 
cations specific packages, etc. We term this the "environment" 
of Ada. It is expected that the availability of this environment 
to those who have compliant compilers will be an incentive for 
such compliance. 

A fundamental question is why does the DoD want to get 
involved with national and international standardization. Ada 
is being volved in a single place and does not have the normal 
standards problem of rationalization of divergent definitions and 
implementations. Is not the DoD's control sufficient? 

It may well be that the DoD has sufficient control in- 
ternally and with its contractors . This control may be sufficient 
to carry over to much of U.S. industry. We are not confident that 
this will be sufficient to cover small business, academic, and 
foreign industry. We do, however, feel very strongly about the 
benefits of commonality, specifically those benefits to the DoD 
of universal commonality, the ability to pick up programs generated 
elsewhere, transfer of technology, availability of compilers 
generated elsewhere, and most significantly the increacend 
availability of other sources on which we can draw for hardware 
and software contractors, increacing competition. 

For the advantages this will provide, the DoD is 
prepared to relinguish some control to the proper authorities, 
the matter is certainly up for negotation. Ada Control Board will 
be established to maintain and interpret the standard. It seems 
reasonable to have representatives on this group from any nation 
having a significant committment to the language. Consider that 
group as the sponsoring body, presently the U.S. DoD with repre- 
sentatives of U.K., France and Germany. 



It has certainly been true that the design of ADA, and 
the entire project leading up to it, has been an inter- 
national effort, as I believe has been evidenced here 
today. It would be a shame if this opportunity to assu- 
wl>« f ™^c3 e ^ginning, a worldwide single definition 
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In light of the resolution 6 intent, we consider that 
we are now in a phase of simultaneous comment from lo- 
cal, national, and international bodies. This was the 
purpose of the WG 1 Resolution and the SC 5 circula- 
tion of the documents (N 499, N 504, N 505). 
Several hundred comments have already been received 
and processed. The results of these comments and fur- 
ther studies will result in a final design document in 
May 1980 (with perhaps an early draft in January 1980). 
At that time we will have a Military Standard, and, one 
expects, a US Government Standard. I belive that at that 
time, with your cooperation, we will have done the pro- 
cessing appropriate in order for SC 5 to recommend Ada 
for international standardization. 
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The University of Nebraska-Lincoln 



Department of Computer Science 

Ferguson Hall 

Telephone (402) 472-2402 

Lincoln, Nebraska 68588 



Pascal User's Group, c/o Andy Mickel 
University Computer Center: 227 EX 
208 SE Union Street 
University of Minnesota 
Minneapolis, MN 55455 

Dear Andy, 



Enclosed is an article for the Pascal News that should be of interest 
to your readers. It describes some observations on error message fre- 
quency, persistence, and apparent student reaction in an introductory 
Pascal class for Computer Science majors and advocates the development 
of better error diagnostics particularly for novice programmers. 

Sincerely, 

David W. Embley ^ 
Assistant Professor 

The University o, Nebraska-Lincoln The University of Nebraska a, Omaha —fheDniversity of Nebraska Medioa, Center 



A STUDY OF SYNTAX ERRORS ENCOUNTERED 
BY BEGINNING PASCAL PROGRAMMERS 

Kirk Baird 

David W. Embley 

Department of Computer Science 

University of Nebraska - Lincoln 

Lincoln, NE 68588 



1. Introduction 

In the 1978-1979 school year, the Computer Science Department at the University of 
Nebraska - Lincoln replaced FORTRAN with PASCAL as the introductory language for Compu- 
ter Science majors. Since PASCAL was known to only a handful of upperclassmen and pro- 
fessors, it was anticipated that beginning students would encounter difficulty finding 
assistance with errors in their programs. The traditional sources of assistance, other 
than the teaching assistant or professor (e.g. the debug consultant, fraternity files, 
or the dorm-floor Comp. Sci. genius) would not be as helpful as before. In this situ- 
ation, increased dependence on the compiler generated error messages was inevitable; 
and even though PASCAL is designed for instructional use, its error diagnostics are 
unfortunately not composed so that the beginning student can readily understand them. 

Anticipating this difficulty, we decided to observe all first semester student programs 
submitted for execution and note error message frequency, error persistence, and appar- 
ent student reaction and catalogue actual causes for each error. The results of these 
observations were to serve as a basis for improving PASCAL error messages or at least 
to provide material for a reference document for beginning PASCAL programmers. 

2. Data Collection 



The students observed were Computer Science majors taking CS 155, Introduction to Com- 
puter Programming, using PASCAL. These students ran their PASCAL programs on an 
IBM 370/148 (later upgraded to a 158) using the September 1977 version of a PASCAL 
compiler developed at Stanford University. 

A special JCL package was developed for use in data -collection. Each time a student 
ran a program, the output, including in-line error messages, was routed to disk. If 
the program compiled without syntax errors, it was allowed to execute, and the output 
was also sent to disk. A copy of all of the temporary disk output including program 
listing and program output was placed in a permanent file and finally routed to the 
printer and given to the student as if it were undisturbed. The permanent file was 
occasionally reblocked and copied to tape. 

The data collected in this manner eventually came to almost six million bytes of stor- 
age. Elementary pattern matching techniques were used to locate and tabulate the 
occurrences of syntax errors in this data. The results of this tabulation appear in 
Appendix I. 

On occasion, listings of random portions of the data were printed, and the syntax 
errors, their cause, and their persistence were analyzed by hand and cataloged. Later 
in the semester, printouts of unsuccessful runs were collected by the professor and 
turned over for analysis and cataloging. The results of this tabulation are reported 
in Appendix II. 



3. Observations 

Three general observations can be made from the data: 1) beginning students interpret 
error messages too literally, 2) differences between standard PASCAL as described in 
the text (Kieburtz, 78) and the version implemented confuse students, and 3) certain 
error messages seem to be particularly ambiguous or misleading. 

3.1 Literal Interpretation 

Given little else, the beginning student is likely to depend unwittingly on the com- 
piler generated error messages, at first taking them too literally. In the Stanford 
compiler as implemented at UNL, an error arrow points to a particular column of a 
line of code and is followed immediately by a list of error message numbers. The 
premise is made that the arrow points to the exact position of the error described by 
the error messages associated with the error numbers. In fact, the error arrow never 
points to the exact position of the error. Most often, it is positioned just past the 
error, usually pointing at the following keyword or identifier. 

More than once a student forgot to put a semicolon at the end of the PROGRAM line and 
found the error arrow pointing to the character following the succeeding keyword, VAR, 
giving the message "SEMICOLON EXPECTED". The student would run the program a second 
time with a semicolon after the keyword (i.e. VAR;), and the compiler would respond 
with an error arrow pointing to the semicolon and the message "SEMICOLON EXPECTED", 
among others. 

Other students inadvertently put a semicolon where a comma belongs in a WRITELN param- 
eter list. The resulting error was ") EXPECTED" with the error arrow positioned near 
the semicolon. Subsequent runs showed students putting right parentheses before, after, 
and in place of the semicolon. 

3.2 A Non- Standard Version 

The second problem is the difference between the standard version of PASCAL and the one 
implemented at UNL. Since some characters were not available, the compiler expected 
standard substitutions such as left-parentheses-vertical-bar for left-square-bracket 
and the at-sign for up-arrow. These obvious distinctions caused relatively few prob- 
lems. 

Some other differences, however, were more detrimental. For example, in the September 
1977 version of the Stanford compiler, the standard identifier MAXINT was not imple- 
mented, nor was PAGE, and WRITELN and its counterparts had to be followed by paren- 
theses in contrast to the syntax diagrams. Several students faithfully adhered to the 
syntax diagrams and appropriately omitted the parentheses only to find their code blem- 
ished with unwarranted syntax errors. The subsequent July 1978 version resolved the 
problems with PAGE and WRITELN but disallowed SET OF CHAR. Hence students copying seg- 
ments of programs from their text with such syntactically legal expressions as 
CH IN (| 'A' ..'Z 1 |) or N >= SQRT (MAXINT) would get syntax errors. 

3.3 Ambiguity 

The third problem is the ambiguity of the error message itself. There are a handful of 
often occurring ambiguous error messages including "ILLEGAL SYMBOL" and "ERROR IN VARI- 
ABLE" and less often occurring messages such as "SEMICOLON EXPECTED" and "TYPE CONFLICT 



OF OPERANDS". In fact, "ILLEGAL SYMBOL" and ERROR IN VARIABLE 
forty percent of all error messages observed. 



accounted for almost 



One of the most often committed blunders exemplifies, the novices reaction to these 
ambiguous messages. Students would precede an ELSE with a semicolon; the resulting 
error message, "ILLEGAL SYMBOL", pointed at the blank following the ELSE. Students 
replaced this blank with almost anything, including another THEN, another semicolon, a 
BEGIN, or a new line. 

The reason ambiguous error messages hold such a majority of the total is twofold: 

1) the very fact that the error message is unclear causes the student to repeat it, 
sometimes with changes, and at times with the innocent hope that it will go away, and 

2) many error messages have more than one cause and are unclear because the message 
has to be general enough to cover all cases. 

4. What can be done ? 

Ideally, the compiler should be modified, with the beginning student in mind, to give 
more appropriate error messages. This modification should involve more than mere cos- 
metic changes to the error messages. Most likely, additional messages are needed, and 
a finer distinction among possible causes should be incorporated particularly for 
ambiguous and high frequency error messages. 

Not having developed the compiler ourselves, we were not in a position to make these 
intricate alterations. We were, however, in a position to alter the error message 
table so that an error message would include a listing of the most prevalent potential 
sources' of the error. Although this option was at our disposal, we rejected it for a 
number of reasons. No beginning student could remain calm at seeing a hard-worked-on, 
twenty-line PASCAL program intermingled with two hundred lines of error messages. 
Moreover, there are certain to be sources of errors that have not been cataloged; a 
given student assignment might generate a particular error message a thousand times 
even though it never appeared during the semester observed. In addition, because 
Stanford is regularly updating its compiler, such alterations would soon be made obso- 
lete. For example, when a literal character string spanned two source lines on the 
September 1977 version, the error message generated was "IMPLEMENTATION RESTRICTION". 
In subsequent versions, the error is "STRING CONSTANT CANNOT EXCEED SOURCE LINE". 

In view of these difficulties, it was thought best to provide a supplementary handout 
that could be updated from time to time. This handout (Baird, 79) provides a list of 
the most frequently encountered errors and their typical causes. Another advantage 
of a handout over a cosmetic alteration of the syntax error table is that additional 
documentation and helpful suggestions can also be included. In addition to syntax 
errors, this handout documents differences between the UNL Stanford compiler and 
standard PASCAL, describes runtime errors and what to do about them, lists compiler 
options, and shows and explains a sample program listing. 

We encourage PASCAL implementors to make the effort to. provide better error messages 
particularly for novice programmers. We would be interested to hear of such projects 
in progress and would eventually like to obtain a compiler with error messages that 
are more palatable to the beginner. 
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APPENDIX I 

These errors were tabulated from students running PASCAL as an introductory programming 
language, using the Stanford PASCAL compiler. The actual error message is listed in 
order of decreasing occurrence. Errors of insignificant occurrence are omitted. 



Appendix II 

The following error messages were found in the programs of beginning PASCAL students 
and were catalogued as to what caused them. Only the more recurrent causes are listed; 
the obvious causes are not listed (e.g. error 14, ";" EXPECTED, does not list missing 
semicolon as a cause). 
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ILLEGAL SYMBOL 

IDENTIFIER IS NOT DECLARED 

ERROR IN VARIABLE 

"END" EXPECTED 

ERROR IN FACTOR 

END OF FILE ENCOUNTERED 

IMPLEMENTATION RESTRICTION 

ILLEGAL TYPE OF OPERAND (S) 

":=" EXPECTED 

") " EXPECTED 

IDENTIFIER DECLARED TWICE 

":» EXPECTED 

TYPE CONFLICT OF OPERANDS 

ERROR IN TYPE 

IDENTIFIER IS NOT OF APPROPIATE CLASS (sic) 

ERROR IN DECLARATION PART 

";" EXPECTED 

ERROR IN TYPE OF STANDARD FUNCTION PARAMETER 

IDENTIFIER EXPECTED 

ILLEGAL TYPE OF EXPRESSION 

»*" EXPECTED 

"THEN" EXPECTED 

ERROR IN TYPE OF STANDARD PROCEDURE PARAMETER 

"BEGIN" EXPECTED 

"UNTIL" EXPECTED 

"DO" EXPECTED 

F-FORMAT IS FOR REAL TYPE ONLY 

" (" EXPECTED 

TYPE OF VARIABLE IS NOT A RECORD 

ERROR IN CONSTANT 

NUMBER OF PARAMETERS DOES NOT AGREE BITK DECLARATION 

TYPE CONFLICT 

"OF" EXPECTED 

ii-ii EXPECTED 

"," EXPECTED 

"TO" OR "DOWNTO" EXPECTED 

LOW BOUND EXCEEDS HIGHBOUND 

NUMBER EXPECTED 

INCOMPATIBLE SUBRANGE TYPES 

INDEX TYPE IS NOT COMPATIBLE WITH DECLARATION 

ILLEGAL PARAMETER SUBSTITUTION 

ILLEGAL TYPE OF LOOP CONTROL VARIABLE 

ASSIGNMENT TO STANDARD FUNCTION IS NOT ALLOWED 

UNDECLARED LABEL 

ERROR IN REAL CONSTANT : DIGIT EXPECTED 

TOO MANY ERRORS IN THIS SOURCE LINE 



PERCENT 
OCCURRENCE 
27.0 
18. 
11. 
04. 
04. 
04. 
03. 
02. 
02. 
02. 
02. 
01. 
01, 
01. 
01.5 
01.4 
01.3 
01.0 
00.8 
00.7 
00.6 
00.6 
00.5 
00.4 
00.4 
00. 
00. 
00. 
00. 
00. 
00. 
00. 
00.1 
00.1 
00.1 
00.1 
00.1 
00.1 
00.1 
00.1 
00.1 
00.1 
00.1 
00.1 
00.1 
00.1 



2: IDENTIFIER EXPECTED 

a) extra comma in list 

b) used TYPE as a variable name 

c) missing quote in character literal 

d) previous error in declaration 

e) used zero instead of in identifier 



4: ")" EXPECTED 

a) => used instead of >= 

5: ":" EXPECTED 

(note: in Stanford PASCAL, the colon is a viable 
substitute for . .) 

a) tried to use FILE as a variable name 

b) CASE without END 

c) TO used instead of .. 



6: ILLEGAL SYMBOL 



a semicolon 



a) previous statement missing 

b) semicolon precedes ELSE 

c) misspelled keyword 

d) => instead of >= 

e) missing quote in character literal 

f) missing ( in comment 

g) = used instead of := 
h) extra END 
i) DO used instead of 
j) TO used instead of 
k) = used instead of : 
lj END missing on CASE statement 
m) comma missing in list 

n) spaces within an identifier 

o) comma or colon used instead of a semicolon 



8: "OF" EXPECTED 

a) tried to use FILE as a variable name 

b) identifier declared twice 



BEGIN 
for RECORD within RECORD 



10: ERROR IN TYPE 

a) tried to use type as a variable name 

b) colon used instead of equal sign 

13: "END" EXPECTED 

a) forgot END for RECORD 

b) used TYPE as a variable name within record 

1.4: «;« EXPECTED 

(n0te L^ iS 1 err0r .° n ?- y ° ccurs ¥ithin th * declaration part 
semicolons missing within the block are flagged with 
error 6: ILLEGAL SYMBOL) 

a) illegal characters within PROGRAM identifier 

b) forgot END for RECORD ^J-ner 

c) tried to redefine TYPE within a RECORD 

16: ••=•» EXPECTED 

a) colon used to instead of equal sign 

b) tried to use TYPE as a variable within a RECORD 

18: ERROR IN DECLARATION PART 

a) VARIABLES used instead of VAR 

19: ERROR IN FIELD LIST 

a) forgot END for RECORD 

50: ERROR IN CONSTANT 

a) ... used instead of . . 

b) TO used instead of .. 

c) variable list used as an array index 

51: ":=»» EXPECTED 

a) soused instead of : = 

b) misspelled name of procedure identifier 



58: ERROR IN FACTOR 

a) => used instead of >= 

b) literal character used without quotes 

c) real fraction constant used without leading zero 



59: ERROR IN VARIABLE 

a) missing quote 

b) missing semicolon 

c) missing comma in list 

d) misspelled procedure identifier 

e) := used instead of = in expression 

f) misspelled AND 

g) illegal charactrer in identifier 



101: IDENTIFIER DECLARED TWICE 



a) identifier used once as an element in a user defined 
datatype and once as a simple variable 



102: LOVBODND EXCEEDS HIGHBOOND 
a) TO used instead of . • 

103: IDENTIFIER IS NOT OF APPROPRIATE CLASS 



a) semicolon missing before WRITE 

b) previous error in declaration 

c) no END for CASE statement 

d) missing quote for literal string 



104: IDENTIFIER IS NOT DECLARED 

a) misspelled identifier 

b) misspelled keyword 

c) missing quote in character literal 

d) imbedded blanks within an indentifier 



116: ERROR IN TYPE OF STANDARD PROCEDURE PARAMETER 

a) tried to read a user defined datatype qualified record 
identifier broken between source lines 



125: ERROR IN TYPE OF STANDARD FUNCTION PARAMETER 
a) passed integer to TRUNC 



129: TYPE CONFLICT OF OPERANDS 

a) integer assigned a real result 

b) misspelled identifier 

c) / used instead of DIV 

d) literal character string not the same size as 

ARRAY OF CHAR it is assigned to 



134: ILLEGAL TYPE OF OPERAND (S) 



255: TOO MANY ERRORS IN THIS SODRCE LINE # 



a) => used instead of >= 

b) previous error in declaration 



(note: the compiler only lists the first nine syntax 
errors of a source line) 



136: SET ELEMENT MUST BE SCALAR OR SUBRANGE 

a) set written inside square brackets 

e.g. X : SET OF BOOLEAN; .... (I X |) 



138: TYPE OF VARIABLE IS NOT AN ARRAY 

a) = used instead of := when assigning an array 

139: INDEX TYPE IS NOT COMPATIBLE KITH DECLARATION 
a) previous error in declaration 



398: IMPLEMENTATION RESTRICTION 

a) WRITELN (a record) 

b) literal character string > 64 characters 

c) SETs OF CHAR are disallowed on the compiler 



□□□□□□□□ 



140: TYPE OF VARIABLE IS NOT A RECORD 
a) previous error in declaration 



143: ILLEGAL TYPE OF LOOP CONTROL VARIABLE 
a) previous error in declaration 

144: ILLEGAL TYPE OF EXPRESSION 
a) := used instead of = 

145: TYPE CONFLICT 

a) previous error in declaration 

147: LABEL TYPE INCOMPATIBLE KITH SELECTING EXPRESSION 
a) no END for CASE statement 



Applications 



AYLI - As You Like It 



Production programming in Pascal requires a number of source code manipulation tools 
With them appropriate application specific syntactic sugar and common multi-program pro- 
cedure and data structure definitions can be managed. Doug Comer's MAP is such a pro- 
gram. K 

Tram's complex arithmetic routines and Judy Bishop's/Arthur Sale's string routines 
are examples of typical library source utilities. Barry Smith also sent in a small 
string package. Take your pick. After all, with Pascal you can have it AYLI 



152: NO SUCH FIELD IN THIS RECORD 

a) misspelled field 

b) previous error in declaration 



156: MULTIPLY DEFINED CASE LABEL 



a) no END for CASE statement 

b) missing quote within CASE statement 

c) ELSE preceded by semicolon in CASE statement 



CORRECTIONS 



A Class of Easily . . . 
in example #3 change 
"Y = 0" to "Y = 9" 



Pascal News #15 



Applications 



S-5 "ID2ID" (See PN 15, September 1979, page 31.) 

Jim Miner spotted two typos in the published version of ID2ID. He also provided code to 
improve error processing by handling unclosed strings correctly as well as an unexpected 
EOF inside comments. - Andy Mickel 

Correct typographical errors: 

Replace line 172 by: 

it P2~.Bal = HigherRight then Pl~.Bal := HigherLef t 

Replace line 314 by: 

ImportantChars := Letters AndDigits + ['(', '{', ""]; 

Improve error processing: 

Replace line 3 by: 

* James F. Miner 79/06/01, 79/09/30. 

Insert after line 275: 

label 

1 < TO ESCAPE EOF INSIDE OF A COMMENT }; 

Replace lines 338 and 339 by: 

'in source program.') 
else begin Write (Target, Source^) ; Get (Source) end 



Insert after line 345: 



Write (Target, Source"); Get (Source); 



Delete line 347. 



Replace lines 350, 351, and 352 by: 

if E0Ln( Source) then 

begin WriteLn (Target) ; ReadLn ( Source ) ; 

if EOF (Source) then goto 1 { EXIT SCAN } 
end 
else begin Write (Target , Source"); Get (Source) end 

Replace lines 362, 363, and 364 by: 

if E0Ln( Source) then 

begin WriteLn (Target ) ; ReadLn ( Source ) ; 

if EOF (Source) then goto 1 < EXIT SCAN > 
end 
else begin Write (Target, Source"); Get(Source) end 

Replace line 372 by: 
end ; 
1: < COME FROM EOF INSIDE OF COMMENT } 



***************** 



USER MANUAL - REFERENCER 
Version S-02.01. 1Q7Q December 17 



1 t INTRODUCTION 

The Referencer program is a software tool intended to assist programmers in 
finding their way around Pascal program listings of non- trivial size. In 
keeping with a basic philosophy that software tools should have distinct 
and clear purposes (as indeed most craftsmen desire), the function of 
Referencer has been defined as providing a compact summary of 
procedure- headings in .& program . and a, table of calls made bv each 
procedure . It thus provides information on the first-order procedural 
interfaces. 

The products of Referencer may serve also as an adjunct to a full cross- 
reference, because in presenting less information Referencer produces a 
more convenient summary. Additionally, for those people who wish to change 
the syntax of Pascal to require repetition of a procedure-heading at the 
occurrence of the block of a forward-declared procedure, it will serve as a 
reminder that language changes are not the only answer to every problem. 



2. USE OF REFERENCER 

Version S-02.01 of Referencer, the distribution version, has no options to 
be set. It reads from the input file, expecting to find a complete Pascal 
program on this textfile. Although the results with syntactically incorrect 
programs are not guaranteed, Referencer is not sensitive to most flaws. It 
cares about procedure, function, and program headings, and about proper 
matching of begins and cases with ends in the statement- parts. 

The two tables are produced on the file output . Referencer does not try to 
format the headings to fit them into a device-line width; it leaves them 
pretty much as they were entered into the program, except for indentation 
alignment. The first table thus benefits from a wide print-line. The 
second table has a constant in the program which controls its width, and 
the distributed version requires 132 characters of print positions. 

Thus, use of Referencer involves simply executing it, with the attachment 
of the input file to some program text, and the direction of the output 
file to some suitable printing device. 



T, LEXICAL STRWTUBB TABl.fi 

The first table (see Appendix) displays the lexical structure and the pro- 
cedure headings. (The term procedure means procedure, function, or program 
in this documentation unless otherwise stated.) As the program is read, 
each heading is printed out with the line-numbers of the lines in which it 
occurs. The text is indented on the first line so as to display the 



lexical nesting. Subsequent lines are adjusted left or right so as to 
maintain their relative position with respect to this 'mother* line. On 
rare occasions it may not be possible to achieve this adjustment if there 
are insufficient leading spaces to delete on the dependent lines, and then 
the display will suffer. 

In this context, the 'procedure heading' is taken to mean all the text 
between and including the opening reserved word of the heading, and the 
semicolon that separates it from the text that follows. What will be 
printed is everything contained on the lines that contain this heading. 
While this definition of procedure heading is not the one in the draft Pas- 
cal Standard, it is a pragmatic convenience to consider it thus rather than 
as the syntactic construct. 

The prime use of this table is in understanding programs; it documents the 
interfaces to each procedure, their lexical nesting, and where the headings 
are- located. 



4. THE CALL-STRUCTURE TABLE 

The second table is produced after the program has been scanned completely, 
and -is the result of examining the internal data. For each procedure 
listed in alphabetical order, the table holds: 

- The line-number of the line on which its heading starts. 

- Unless it was external or formal (and had no corresponding block) , 
the line-number of the begin that starts the statement-part (the 
body). 

- In the Notes column, the characters 'ext' are printed if the pro- 
cedure has an external body (declared with a directive other than 
forward ) . and the characters 'fml' are printed if it is a formal pro- 
cedural or functional parameter. If a number appears, the procedure 
has been declared forward and this is the line-number of the line 
where the block of the procedure begins; the second part of the two- 
part declaration. 

- A list of all. user-declared procedures immediately called by this 
procedure. In other words, their call is contained in the 
statement-part. The list is in order of occurrence in the text; a 
procedure is not listed more than once if it is called more often. 

This table may be useful in finding the components of a procedure as they 
are squashed into different places in the listing by the flattening effects 
of syntax. It may also be useful in seeing the inter-dependencies of the 
procedures of the program. 



5. LIMITATIONS 



As mentioned before, the behaviour of Referencer when presented with 
incorrect Pascal programs is not guaranteed. However, it has been the 
intention that it be fairly robust, and there are not too many flaws that 



will cause it to fail. The most critical features, and therefore those 
likely to cause failure if not correct are the general structure of the 
procedure heading (reserved word followed by name with optional parameter- 
list with balanced parentheses followed by semicolon and either reserved 
word or directive) , and the correct matching of end with each begin or case 
in each statement- part (since this information is used to detect the end of 
a procedure) . 

If an error is explicitly detected, and Referencer has very few explicit 
error checks and minimal error-recovery, a message is printed out that 
looks like this: 







FATAL ERROR - No identifier after prog/proc/func 
procedure ( t : TransactionType ) ; 



AT FOLLOWING LINE 



The line of text printed is where the program was when it got into trouble; 
like all diagnoses this does not guarantee that the correct parentage is 
ascribed to the error. Processing may continue despite the fatal error for 
a while, but the second table will not be produced. 

Referencer is believed to accept the full Pascal language, as described in 
the draft proposal submitted to ISO, and to process it correctly. 



6. PORTABILITY 

It is believed that Referencer uses only Standard Pascal features according 
to the draft proposal submitted to ISO. 

It should be relatively easy to transfer it to other Pascal processors. It 
does not use packing, except for pseudo-strings of characters. Neither 
does it use dispose, though a possible usage is marked in the program. The 
small amount of data stored does not warrant their use if it might imperil 
portability. It requires the use of small sets of at least set of 0..15, 
and a set of char. Those who have not a set of char available can fairly 
easily program around it, and complain to their Pascal suppliers. The 
names are stored internally in a canonic letter-case (lower-case in Version 
S-02.01), with a set indicating those to be transformed on output. This 
strategy should enable users to modify it to run even on CDC's 6+6 bit 
lower-case system, and on one-case systems. The program implements the 
Pascal Standard's attitude towards letter-case. 



7. SYSTEM NOTES AND MODIFICATIONS 

7.1 PARAMETERIZED CONSTANTS 

The heading of the program contains information on altering: 

- The significance limit of identifiers (currently 16 characters). 
This should not be reduced below 10 as it will be difficult to dis- 
tinguish identifiers and reserved words. 



The difference between upper-case and lower-case letters. EBCDIC 
users will probably need to change only this single constant. 

The line width for table 2, which automatically affects the number of 
columns of called procedure names. The distributed version has this 
set at 132, which allows 5 columns of 16-character names across the 
page. Setting it to 54, which allows a single column, is an useful 
variation. 

The number of indentation spaces per level. 



7.2 INTERNAL STRUCTURES 

Procedure information is held in an 'Entry' record, each of which is linked 
into two binary trees by alphabetical order of name (ignoring letter-case). 
Each 'Entry' record contains a linked list of 'UsageCell's which point to 
procedures called from that procedure. There is also a lexical stack 
display, composed of 'StackCell' s. Similarly, these point to the currently 
nested procedures during the first phase of processing. Each stach cell 
also contains a root pointer which holds a "scope-tree" which contains all 
the names declared at this level. A single "super- tree" contains all the 
procedure names. The scope- trees are traversed during searching for names, 
and the supertree is used to produce the final table. 

The final tables are capable of further interpretation which has not been 
done here in the interests of simplicity of the resulting software tool. 
For example, recursivity may be deduced from the data, and small modifica- 
tions would allow the keeping of call- frequency counts. 

As mentioned earlier, each name is separated into a case- independent com- 
ponent and a solely-case component for storage. The identifiers are recon- 
structed at the time of display. In the case where not all occurrences of 
an identifier have the same visual representation, Referencer will thus 
still recognize them as the same, and will use the first occurrence as the 
display form. Referencer could easily check the Identity of such forms, 
but any error messages would spoil the tables and it has not been done in 
line with the philosophy that each tool has a particular purpose. 
General-purpose tools are often such compromises that they are successful 
at none of their tasks... 



7t3 EFFICIENCY 



As might be expected, Referencer spends most of its time in NextCh, NextTo- 
ken, Readldent, IgnoreComment and FindNode. As a guide, the following 
information was collected while. Referencer processed its own text. The 
counts under the "Statements" column are the maximum statement counts for 
any statement within the procedure body. All counts have been rounded and 
depend to some extent on the use of spaces and tabs in the source file. 



Procedure 


Calls 


Statements 


NextCh 


30800 


30800 


NextToken 


2600 


8700 


Readldent 


1600 


9000 


FindNode 


3800 


4500 


IgnoreComment 


102 


13500 



The space usage of Referencer is very small, except perhaps for the program 
itself. 

On Berkeley Pascal running under UNIX on a PDP-11/34, processing Referencer 
by itself requires about 96 seconds of processor time. This is about 10.6 
lines per second. The code occupies about 9,000 bytes of storage. Berke- 
ley Pascal is an interpretive system Intended for student users, and is 
therefore rather slow in comparison with compilers with native code genera- 
tion. 



8. ERROR REPORTING 

If any errors in processing Standard Pascal programs are detected, please 
write to the author at the following address with the exact details. Prob- 
lems with processing incorrect or non-Standard programs are not interest- 
ing. 

Prof A. H.J. Sale 

Department of Information Science 

University of Tasmania 

Box 252C, G.P.0. Hobart 

Tasmania 7001 

Any experiences with the portability of this tool are also welcomed. A 
Technical Report on its design and structure is in preparation. 



HISTORY 



This program grew out of the proper haunts of good ideas (the coffee-room) 
and several discussions of what one would like from such a tool. 
A.J.Currie, at the University of Southampton, produced the first prototype 
program of 231 lines. Based on this experience and the problems in accept- 
ing the full Pascal language, A. H.J. Sale (on leave from the University of 
Tasmania) wrote the current version of just over 1000 lines. The resulting 
program is now about 20$ slower than the prototype, but it is believed to 
be a more modifiable and a correct tool. 

The current program was written in 4 days. It does not fit into any 

integrated system of software tools but has been designed with the basic 

view that software tools should be plentiful, correct, portable, flexible, 
and single-purpose. All attributes are equally important. 



^W<d§^ 



^iV^^iV^^iV 



0001 
0002 
0003 
0004 
0005 
0006 
0007 
0008 
0009 
0010 
0011 
0012 
0013 
0014 
0015 
0016 
0017 
0018 
0019 
0020 
0021 
0022 
0023 
0024 
0025 
0026 
0027 
0028 
0029 
0030 
0031 
0032 
0033 
0034 
0035 
0036 
0037 
0038 
0039 
0040 
0041 
0042 
0043 
0044 
0045 
0046 
0047 
0048 
0049 
0050 
0051 
0052 
0053 
0054 
0055 
0056 
0057 
0058 
0059 
0060 
0061 
0062 
0063 
0064 
0065 



program Re ferencer( input , out put) ; 
{ 



PASCAL PROCEDURAL CROSS-REFERENCER 

(c) Copyright 1979 A. H.J. Sale, Southampton, England. 

DEVELOPMENT 

This program is a software tool developed from a prototype by 
A.J.Currie at the University of Southampton, England. The proto- 
type of 231 lines of source text was used firstly as a basis for 
extensions, and then rewritten to assure correctness by 
A. H.J. Sale, on leave from the University of Tasmania and then 
also at the University of Southampton. The current version was 
stabilized at 1979 December 4; the development time being es- 
timated at 4 man-days from prototype to production. 

PURPOSE 

The program reads Pascal source programs and produces two tables 
as output. These tables are procedural documentation and cross- 
references. One documents all procedure or function headings in 
a format that illustrates lexical nesting. The other tables 
gives the locations of heading, block, and body for each pro- 
cedure and function, and what procedures and functions it immedi- 
ately calls. 

There is a User Manual for this program; if it has not been pro- 
vided with your installation write to: 

Department of Information Science 

University of Tasmania 

P.O.Box 252C, G.P.0. Hobart 

Tasmania 7001 
and ask for the Technical Report on Referencer, if it is still 
available. The program is written to be portable and is believed 
to be in Standard Pascal. 

Permission is granted to copy this program, store it in a comput- 
er system, and distribute it, provided that this header comment 
is retained in all copies. 



PROGRAM ASSERTIONS 

Pre-Assertion P1: 

"The file input contains a representation of a correct 
Standard Pascal program, in the ISO Reference form." 

Post-assertion P2: 

P1 and "the file output contains a representation of the 
two tables described above, which correctly describe facts 
about the program," 



const 

{ This constant is the number of significant characters kept in 
the identifier entries. It can readily be changed. It is not 
advised that it be reduced below 10 (reserved words get to 9). } 
SigCharLimit = 16; 

{ This must always be (SigCharLimit - 1). It is used simply to 
reduce the set range to have a lower bound of 0, not 1. } 



0066 
0067 
0068 
0069 

0070 

0071 

0072 

0073 

0074 

0075 

0076 

0077 

0078 

0079 

0080 

0081 

0082 

0083 

0084 

0085 

0086 

0087 

0088 

0089 

0090 

0091 

0092 

0093 

0094 

0095 

0096 

0097 

0098 

0099 

0100 

0101 typ< 

0102 

0103 

0104 

0105 

0106 

0107 

0108 

0109 

0110 

0111 

0112 

0113 

0114 

0115 

0116 

0117 

0118 

0119 

0120 

0121 

0122 

0123 

0124 

0125 

0126 

0127 

0128 

0129 



SetLimit = 15; 

{ This constant is used to convert upper-case letters to lower-case 
and vice-versa. It should be equal to ord('a') - ord('A'). } 
UCLCdisplacement = 32; 

{ This constant determines the size of the input line buffer. 
The maximum acceptable input line is one smaller because a sentinel 
space is appended to every line. } 
LineLimit = 200; 

{ This constant determines the maximum width of the printing of the 
second cross-reference table. The program deduces how many names 
will fit on a line. } 
LineWidth = 132; 

{ This determines the indentation of the lex-levels. } 
Indentation = 4; 

{ These constants are used for the sketchy syntax analysis. 
They are collected here so that their lengths may be altered If 
SigCharLimit is altered. } 



Sprogram 

Sprocedure 

Sfunction 

Slabel 

Sconst 

Stype 

Svar 

Sbegin 

Scase 

Send 

Sforward 

Spaces 



= ' program 

= 'procedure 

= 'function 

= 'label 

= ' const 

= 'type 

= 'var 

= 'begin 

= ' case 

= 'end 

= ' forward 



Natural 
Positive 

SixChars 

SigCharRange 
SetRange 

PseudoString 
String Cases 

LineSize 
Linelndex 

SetOfChar 

ProcKind 

PtrToEntry 

ListOfUsages 

PtrToStackCell 

TokenType 



= 0. .maxint; 
= 1.. maxint; 



= packed array[1..6] of char; 

= 1.. SigCharLimit; 
= 0.. SetLimit; 

= packed array [SigCharRange] of char; 
= set of SetRange; 

= 1 . .LineLimit; 
= 0. .LineLimit; 

= set of char; 

= (FwdHalf ,AllFwd, Short form, Formal, Out side, Not Proc); 

= r Entry; 

= t UsageCell; 

= I StackCell; 

= (OtherSy , NameSy ,LPar enSy , RParenSy , ColonSy , 
SemiColSy,PeriodSy,AssignSy,SubRangeSy); 



{ This type represents a procedure or function identifier found 



0130 

0131 

0132 

0133 

0134 

0135 

0136 

0137 

0138 

0139 

0140 

0141 

0142 

0143 

0144 

0145 

0146 

0147 

0148 

0149 

0150 

0151 

0152 

0153 

0154 

0155 

0156 

0157 

0158 

0159 

0160 

0161 

0162 

0163 

0164 

0165 

0166 

0167 

0168 

0169 

0170 

0171 

0172 

0173 

0174 

0175 

0176 var 

0177 

0178 

0179 

0180 

0181 

0182 

0183 

0184 

0185 

0186 

0187 

0188 

0189 

0190 

0191 

0192 

0193 



during processing of a program. The fields are used as follows: 
procname & caseset = representation of name 



- linenumber 

- star to f body 

- forwardblock 

- status 

- left, right 

- before, after 

- calls 

- localtree 
} 

Entry = 

record 

procname 
caseset 
linenumber 
startofbody 
left, right 
before, after 

calls 
localtree 
case status : 



= where heading starts 

= where begin of statement-part starts 

= where forward-declared block starts . 

= kind or status of name 

= subtrees of the scope- level tree 

= subtrees of the supertree 

= a list of the procedures this calls 

= the scope tree for the interior 



: PseudoString; 
: StringCases; 
:. Natural; 
: Natural ; 
: PtrToEntry; 
: PtrToEntry; 

: ListOf Usages; 
: PtrToEntry; 
ProcKind of 



FwdHalf,Shortform, Formal, Out side, NotProc: 

0; 

AllFwd: 

( forwardblock: Natural ) 



end; 



{ This type records an instance of an activation of a procedure or 
function* The next pointers maintain an alphabetically ordered 
list; the what pointer points to the name of the activated code. } 
UsageCell = 
record 

what: PtrToEntry; 
next: ListOfUsages 
end; 

{ This type is used to construct a stack which holds the current 
lexical level information. } 
StackCell = 
record 

current: PtrToEntry; 
scope tree: PtrToEntry; 
substack: PtrToStackCell 
end; 



lineno 

chno 

total 

depth 

level 

pretty 



: Natural; 
: Linelndex; 
: Linelndex; 
: Natural; 
: -L.maxint; 
: Natural; 



{ These are used to align the lines of a heading. } 
adjustment : (First , Other ) ; 
movement : integer; 

{These are true, respectively, if line-buffers need to be 
printed before disposal, and if any errors have occurred. } 
printflag : Boolean; 
errorflag : Boolean; 



ch 



char; 
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token : TokenType; 

symbol : PseudoString; 

symbolcase : StringCases; 

savesymbol : PseudoString; 

line : array[LineSize] of char; 

super root : PtrToEntry; 

stack : PtrToStackCell; 

{ The remaining variables are pseudo-constants. } 



alphabet 
alpha nums 
uppercase 
digits 
usefulchars 



SetOf Char ; 
SetOfChar; 
SetOfChar; 
SetOfChar; 
SetOfChar ; 



'); 



namesperline : Positive; 

procedure Printline; 
var 

i : LineSize; 
begin 

write( output , lineno: 5, 
i := 1; 

{ Is this the first time in a run or not? } 
if adjustment = First then begin 

{ Ignore any leading spaces there happen to be. } 
while (i < total) and (line[i] = ' ' ) do 

i := succ(i); 
{ Compute the adjustment needed for other lines, 
movement := (level * Indentation) - (i - 1); 
adjustment := Other; 
{ Insert any necessary indentation } 
if level > then 

write (output, » ': (level*Indentation) ) ; 
end else begin 

{ It wasn't the first time, so try to adjust this 
line to align with its mother. } 
if movement > then begin 

write (output, ' ': movement) 
end else if movement < then begin 

while (i < total) and (line[i] = ' ' ) and 
(i <= -movement) do begin 
i := succ(i) 
end 
end 
end; 

{ Write out the line. } 
while i < total do begin 
write (output, line[i]); 
i := succ(i) 
end; 

writeln( output) 
end; { PrintLine } 

procedure Error(e: Positive); 

{ This procedure is the error message repository. } 

begin 

errorflag := true; 

write (out put, 'FATAL ERROR - '); 
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end; 



case e of 

1: write( output , 

2: write ( output , 

3: write ( output , 

4: write( output , 

5: write( output , 
end; 

{ We shall print the offending line too. } 
writeln( output, ' - AT FOLLOWING LINE'); 
adjustment := First; 
PrintLine 
{ Error } 



No "program" word'); 
No identifier after prog/proc/func 1 ) ; 
Token after heading unexpected'); 
Lost ".", check begin/case/ends ' ); 
Same name, but not forward-declared 1 ) 



procedure NextCh; 
begin 

if chno = total then begin 
if printflag then 

PrintLine; 
total := 0; 

while not eoln( input) do begin 
total := succ( total); 
read( input, line[ total]) 
end; 
total := succ( total); 
line[ total] := ' '; 
read In (input); 
lineno := lineno + 1; 
chno : = 1 ; 
ch := line[1] 
end else begin 

chno := succ(chno); 
ch := line[chno] 
end 
end; { NextCh } 

procedure PushCnewscope: PtrToEntry) ; 
var 

newlevel: PtrToStackCell; 
begin 

new( newlevel) ; 

newlevelT .current := newscope; 
newlevelT .scope tree := nil; 

newlevelT .substack := stack; 

stack := newlevel; 

level := level + 1 
end; { Push } 

procedure Pop; 
var 

oldcell: PtrToStackCell; 
begin 

stack? . current! .localtree := stack! .scopetree; 

oldcell := stack; 

stack := oldcell! .substack; 

{ *** dispose (oldcell); *«* } 

level := level - 1 
end; { Pop } 

procedure FindNode(var match : Boolean; 

var follow : PtrToEntry; 
thisnode: PtrToEntry); 
begin 

match := false; 

while (thisnode <> nil) and not match do begin 
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end; 



follow := thisnode; 

if savesymbol < thisnodet .procname then 

thisnode := thisnode! .left 
else if savesymbol > thisnode! .procname then 

thisnode := thisnode! .right 
else 

match := true 
end 
{ FindNode } 



function MakeEntry (mainprog: Boolean; 

proc : Boolean): PtrToEntry; 
{ The first parameter is true if the name in symbol is the 
program identifier, which has no scope. The second parameter 
is true if the name in symbol is that of a procedure or function. 
The result returned is the identification of the relevant record, 
var 

newentry, node: PtrToEntry; 

located: Boolean; 

procedure PutToSuperTree(newnode: PtrToEntry); 

{ This procedure takes the entry that has been created by 

MakeEntry and inserted into the local tree, and also links 

it into the supertree. } 

var 

place : PtrToEntry; 

procedure FindLeaf; 

{ FindLeaf searches the supertree to find where this 
node should be placed. It will be appended to a leaf 
of course, and placed after entries with the same 
name . } 
var 

subroot : PtrToEntry; 
begin 

subroot := superroot; 
while subroot <> nil do begin 
place := subroot; 
if savesymbol < subroot! .procname then 

subroot := subroot! .before 
else 

subroot := subroot! .after 
end 
end; { FindLeaf } 

begin { PutToSuperTree } 

if superroot = nil then begin 

{ Nothing in the supertree yet. } 
superroot : = newnode 
end else begin 

{ Seek the right place } 

FindLeaf; 

with place! do begin 

if savesymbol < procname then 

before := newnode 
else 

after : = newnode 
end 
end 
end; { PutToSuperTree } 

begin { MakeEntry } 

located := false; 
savesymbol := symbol; 



0387 
0388 
0389 
0390 
0391 
0392 
0393 
0394 
0395 
0396 
0397 
0398 
0399 
0400 
0401 
0402 
0403 
0404 
0405 
0406 
0407 
0408 
0409 
0410 
0411 
0412 
0413 
0414 
0415 
0416 
0417 
0418 
0419 
0420 
0421 
0422 
0423 
0424 
0425 
0426 

0427 
0428 
0429 
0430 
0431 
0432 
0433 
0434 
0435 
0436 
0437 
0438 
0439 
0440 
0441 
0442 
0443 
0444 
0445 
0446 
0447 
0448 
0449 
0450 



if mainprog then begin 
new(newentry); 
end else if stack? .scopetree = nil then begin 
{ Nothing here yet. } 
new( newentry); 

stack! .scopetree := newentry 
end else begin 

{ Seek the identifier in the tree. } 
FindNodeC located, node, stack?, scopetree); 
if not located then begin 

{ Normal case, make an entry. } 
new( newentry); 
with nodeT do 

if symbol < procname then 



else 



left := newentry 
e 
right := newentry 



end 



end; 

if not located then begin 

{ Here we initialize all the fields } 
with newentry? do begin 
procname := symbol; 
caseset := symbolcase; 
linenumber : = lineno ; 
startofbody := 0; 
if proc then 

status := Shortform 
else 

status := NotProc; 
left := nil; 
right := nil; 
before := nil; 
after := nil; 
calls := nil; 
localtree := nil 
end; 
MakeEntry := newentry; 
if proc then begin 

PutToSuperTree( newentry) ; 
Push (newentry) 

end 
end else begin 

{ Well, it'd better be forward or else. } 
MakeEntry := node; 

Push(node); 
if nodeT. status = FwdHalf then begin 

stack? .scopetree := node? .localtree; 
node?. status := AllFwd; 
node? .forwardblock := lineno 
end else begin 

Error (5) 
end 
end 
end; { MakeEntry } 

procedure PrintTree(root: PtrToEntry) ; 
var 

thiscell: ListOf Usages; 

count: Natural; 

procedure ConditionalWriteCn: Natural; 

substitute: SixChars); 
begin 



0451 

0452 

0453 

0454 

0455 

0456 

0457 

0458 

0459 

0460 

0461 

0462 

0463 

0464 

0465 

0466 

0467 

0468 

0469 

0470 

0471 

0472 

0473 

0474 

0475 

0476 

0477 

0478 

0479 

0480 

0481 

0482 

0483 

0484 

0485 

0486 

0487 

0488 

0489 

0490 

0491 

0492 

0493 

0494 

0495 

0496 

0497 

0498 

0499 

0500 

0501 

0502 

0503 

0504 

0505 

0506 

0507 

0508 

0509 

0510 

0511 

0512 

0513 

0514 

0515 



{ Write either the substitute string or a number. } 
if n = then 

write (output, substitute) 
else 

write (output, n:6) 
end; { Conditional Write } 

procedure NameWrite(p : PtrToEntry); 

var 

s : SetRange; 
begin 

for s := to SetLimit do begin 

if s in p?. case set then 

write (out put, . » 

chr(ord(p?.procname[s+1])-UCLCdisplacement)) 

else 

write (output, p?.procname[s+1 J) 

end 
end; { NameWrite } 

begin { PrintTree } 

if root <> nil then 

with root? do begin 
PrintTree( before) ; 

write In (output); 
write (output, linenumber: 5); 
ConditionalWrite( startofbody, ' '); 
case status of 

FwdHalf, NotProc: 

write(output, ' eh?'); 
Formal : 

write (output, ' fml'); 
Outside: 

write (output, ' ext'); 
Shortform: 

write (output, ' '); 
AllFwd: 

write (output, forwardblock: 6) 

end; 

write( output, ' '); 

NameWrite (root); 

write (output, * :'); 

thiscell := calls; 

count : = ; 

while thiscell <> nil do begin 

if ((count mod namesperline) = 0) and (count <> 0) 
then begin 
writeln(output); 
write( output, ' ' :35, ' :') 

end; 

write( output, ' '); 

NameWrite (thiscell?. what); 

thiscell := thiscell? .next; 

count := count + 1 
end; 
writeln( output ) ; 

PrintTree( after) 
end 
end; { PrintTree } 

procedure NextToken; 

{ This procedure produces the next "token" in a small set of 

recognized tokens. Most of these serve an incidental purpose; 
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the prime purpose is to recognize names (res'd words or identifiers). 
It serves also to skip dangerous characters in comments, strings, 
and numbers. } 

procedure IgnoreComment; 

{ This procedure skips over comments according to the definition 

in the Draft Pascal Standard. } 

begin 

NextCh ; 
repeat 

while (ch <> ♦«') and (ch <> '}') do 

NextCh; 
if ch = '*' then 
NextCh; 
until (ch = ')') or (ch = '}'); 
NextCh; 
end; { IgnoreComment } 

procedure IgnoreNumbers; 

{ This procedure skips numbers because the exponent part 

just might get recognized as a name! Care must be taken 

not to consume half of a ".." occurring in a construct like 

"1..Name", or worse to consume it and treat the name as an 

possible exponent as in "1..E02". Ugh. } 

begin 

while ch in digits do 

NextCh; 
{ The construction of NextCh, chno & line ensure that 
the following tests are always defined. It is to get 
rid of tokens which begin with a period like .. & .) } 
if (ch = '.') then begin 

if (line[chno+1 ] in digits) then begin 
NextCh; 

while ch in digits do 
NextCh 
end; 
end; 

if (ch = 'E') or (ch = ' e f ) then begin 
NextCh; 
if (ch = '+') or (ch = '-') then 

NextCh; 
while ch in dipits do 
NextCh 
end 
end; { IgnoreNumbers } 

procedure Readldent; 

{ This procedure reads in an identifier } 

var 

j : Positive; 
begin 

token := NameSy; 
symbol := Spaces; 
symbolcase := []; 
J := 1; 

while (j <= SigCharLimit) and (ch in alphanums) do begin 
if ch in uppercase then begin 

symbol[j] := chr(ord(ch) + UCLCdisplacement) ; 
symbolcase := symbolcase + [j-1] 
end else begin 

symbol[j] := ch 
end; 

J := j+1; 
NextCh 
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end; 

{ In case there is a tail, skip it. } 
while ch in alphanums do 
NextCh 
end; { Readldent } 



begin 



token := Other Sy; 
repeat 

if ch in usefulchars then begin 
case ch of 

1 )' : begin 

NextCh; 

token := RParenSy 
end; 

•(': begin 

NextCh; 

if ch = '*' then begin 

IgnoreComment 
end else begin 

token := LParenSy 
end 
end; 

1 { ' : begin 

IgnoreComment 
end; 

" ' ' : begin 

NextCh; 

while ch <> "" do 

NextCh; 
NextCh 
end; 

l 0V1V2V3V4V5', , 6V7V8V9': 
begin 

IgnoreNumbers 
end; 

' : ' : begin 

NextCh; 

if ch = '=' then begin 
token := AssignSy; 
NextCh 
end else begin 

token := ColonSy 
end 
end; 

' . ' : begin 

NextCh; 

if ch <> '.' then 

token := PeriodSy 
else begin 

token := SubRangeSy; 
NextCh 
end 
end; 

' ; ' : begin 
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NextCh; 

token := SemiColSy 
end; 

'A'/B'j'C'/D'j'E'/F'/GS'H'j'IS'J'/K'j'L'/M', 
'NVOVPVQVRVSVTVUVVVWVXVYVZ', 
'a' ,'b' /c'/dVeVf' ,'g' ,'h' , 'i\* j« ,'k ','1' , 'm' , 
'n' ,'o' , ! p ! ,'q* ,'r' ,'s' ,'t' ,'u' ,'v' ,'w' ,'x' ,'y' , f z' : 

begin 

Readldent 

end 

end 
end else begin 

{ Uninteresting character } 
NextCh 
end 
until token <> OtherSy 
end; { NextToken } 

procedure ProcessUnitCprogramid: Boolean); 

{ This procedure processes a program unit. It is called on 

recognition of its leading token = program/procedure/function. 

The parameter records whether we currently have the main program 

identifier in the token, or not. It doesn't have scope. } 

var 

at : PtrToEntry; 

function NamelsInScope: Boolean; 

{ This function is called during the declaration phase 

of a block, and has to find any procedure which gets 

renamed by the scope rules. } 

var 

llevel : PtrToStackCell; 
discovered : Boolean; 
where : PtrToEntry; 
begin 

llevel := stack; 
discovered := false; 
savesymbol := symbol; 
while (llevel <> nil) 

FindNodeC discovered, where 
if not discovered then 

llevel := llevel! .substack 
end; 
if discovered then 

NamelsInScope := (where! . status <> NotProc) 



and not discovered do begin 
llevel! .scopetree) ; 



end 



else 

NamelsInScope := false 
{ NamelsInScope } 



procedure ProcessBlock; 

{ This procedure is called by ProcessUnit when it -has recognized 

the start of a block. It handles the processing of the block, k 

var 

address: PtrToEntry; 

procedure CrossReferencer ; 

{ CrossReferencer is called whenever we have a name which 

might be a call to a procedure or function. The only way 

we tell is by looking in the table to see. If it is, then 

the list of usages of the procedure we are in is scanned and 

possibly extended. } 

var 
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newcell : ListOf Usages; 

ptr : ListOf Usages; 

home : PtrToEntry; 

slevel : PtrToStackCell; 

found : Boolean; 

procedure FindCell; 

{ FindCell is used to scan a List Of Usages to determine 

whether the name already appears thereT -If not, it 

leaves ptr pointing to the tail of the list so that an 

addition can be made. } 

var 

nextptr : ListOf Usages; 
begin 

found := false; 

nextptr := stack! .current! .calls;' 
if nextptr <> nil then 
repeat 

ptr := nextptr; 

found := (ptr! .what! .procname = savesymbol); 
nextptr : = ptr! .next 
until found or (nextptr = nil) 
else 

ptr := nil 
end; { FindCell } 

begin { CrossReferencer } 
slevel := stack; 
found := false; 

while (slevel <> nil) and not found do begin 
FindNode( found, home, slevel! .scopetree); 
if not found then 

slevel := slevel! .substack 
end; 
if found then begin 

if home!. status <> NotProc then begin 
FindCell; 

if not found then begin 
new( newcell); 
if ptr <> nil then 

ptr! .next := newcell 
else 

stack! .current!. calls := newcell; 
newcell! .what := home; 
newcell!. next := nil 



end 



end 
end 
end; { CrossReferencer } 

procedure ScanForName; 

{ This procedure is required to go forward until the 

current token is a name (reserved word or identifier). } 

begin 

NextToken; 

while token <> NameSy do 
NextToken 
end; { ScanForName } 

begin { ProcessBlock } 

while (symbol <> Sbegin) do begin 

while (symbol <> Sbegin) and (symbol <> Sprocedure) and 
(symbol <> Sf unction) do begin 
ScanForName; 
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if NamelsInScope then begin. 

address := MakeEntry( false, false); 
{ MakeEntry made its status NotProc } 
end 
end; 

if symbol <> Sbegin then begin 
ProcessUnitC false); 
ScanForName 
end 
end; 

{ We have now arrived at the body } 
depth : = 1 ; 

stack! .current! .startofbody := lineno; 
NextToken; 
while depth <> do begin 

if token <> NameSy then begin 

NextTOKen 
end else begin 

if (symbol = Sbegin) or (symbol = Scase) then begin 
depth := depth + 1; 
NextToken 
end else if (symbol = Send) then begin 
depth : = depth - 1 ; 
NextToken 
end else begin 

{ This name is a candidate call. But first we 

must eliminate assignments to function values. } 

savesymbol := symbol; 

NextToken; 

if token <> AssignSy then begin 

CrossReferencer 
end else begin 

NextToken 
end 
end 
end 
end 
end; { ProcessBlock } 

procedure ScanParameters; 

{ This procedure scans the parameter list because at the outer 

level there may be a formal procedure we ought to know about. } 

var 

which : PtrToEntry; 

procedure ScanTillClose ; 

{ This procedure is called when a left parenthesis is 

detected, and its task is to find the matching right 

parenthesis. It does this recursively. } 

begin 

NextToken; 

while token <> RParenSy do begin 
if token = LParenSy then 

ScanTillClose; 
NextToken 
end 
end; { ScanTillClose } 

begin { ScanParameters } 
NextToken; 

while token <> RParenSy do begin 
if (token = NameSy) then begin 
if (symbol = Sprocedure) or 

(symbol = Sf unction) then begin 



0835 
0836 
0837 
0838 
0839 
0840 
0841 
0842 
0843 
0844 
0845 
0846 
0847 
0848 
0849 
0850 
0851 
0852 
0853 
0854 
0855 
0856 
0857 
0858 
0859 
0860 
0861 
0862 
0863 
0864 
0865 
0866 
0867 
0868 
0869 
0870 
0871 
0872 
0873 
0874 
0875 
0876 
0877 
0878 
0879 
0880 
0881 
0882 
0883 
0884 
0885 
0886 
0887 
0888 
0889 
0890 
0891 
0892 
0893 
0894 
0895 
0896 
0897 
0898 



{ A formal procedural/ functional parameter. } 

NextToken; 

if token = NameSy then begin 

which := MakeEntry( false , true); 
which! . status := Formal; 
Pop; 

NextToken; 

if token = LParenSy then begin 
{ Skip interior lists. } 
ScanTillClose 
end 
end else begin 
Error(2); 
NextToken 
end 
end else begin 

if NamelsInScope then 

which := MakeEntry( false , false); 
NextToken 
end 
end else begin 

NextToken 
end 
end; 

NextToken 
end; { ScanParameters } 

begin { ProcessUnit } 
print flag := true; 
adjustment := First; 
NextToken; 
if token <> NameSy then 

Error (2) 
else begin 

{ We now have the name to store away. } 

at := MakeEntry(programid, true); 

while not (token in [LParenSy ,SemiColSy, ColonSy] ) do 

NextToken; 
if token = LParenSy then 

ScanParameters ; 
while token <> SemiColSy do 

NextToken; 
PrintLine; 

{ We have now printed the procedure heading. } 
printflag := false; 
writeln( output ) ; 

{ Our next task is to see if there is an attached block. } 
NextToken; 
if token <> NameSy then 

Error(3) 
else begin 

if (symbol <> Slabel) and (symbol <> Sconst) and 

(symbol <> Stype) and (symbol <> Sprocedure) and 
(symbol <> Sf unction) and (symbol <> Svar) and 
(symbol <> Sbegin) then begin 
{ Bloody directive, mate. } 
if symbol = Sforward then 
at! . status : = FwdHal f 
else 

at!. status := Outside; 
Pop 
end else begin 
ProcessBlock; 
Pop 



0899 

0900 

0901 

0902 

0903 

0904 

0905 

0906 

0907 

0908 

0909 

0910 

0911 

0912 

0913 

0914 

0915 

0916 

0917 

0918 

0919 

0920 

0921 

0922 

0923 

0924 

0925 

0926 

0927 

0928 

0929 

0930 

0931 

0932 

0933 

0934 

0935 

0936 

0937 

0938 

0939 

0940 

0941 

0942 

0943 

0944 

0945 

0946 

0947 

0948 

0949 

0950 

0951 

0952 

0953 

0954 

0955 

0956 

0957 

0958 

0959 

0960 

0961 

0962 



end 



end 



end 
end; { ProcessUnit } 



This procedure outlines what is needed to insert the 
predefined names into Referenced s tables. De-box it 
and extend it as needed, 

procedure BuildPreDe fined; 
const 

NoOf Names =2; 
type 

Nameslndex = 1 . .NoOf Names; 
var 

kk : Nameslndex; 

tt : array[NamesIndex] of PseudoString; 

ho hum: PtrToEntry; 
begin 

tt[01] := 'new '; 

tt[02] := 'writeln- '; 

case set := []; 

for kk := 1 to NoOf Names do begin 
symbol := tt[kk]; 
hohum := MakeEntryC false, false ) ; 
hohumj .status := Outside; 

end; 
end; 



*** } 



Version S-02.01'); 



procedure PrintHeading; 

begin 

writelnC output , 'Procedural Cross-Referencer 
writelnC output , *============================ 

writelnC output) 

end; { PrintHeading } 

begin { Referencer } 
superroot := nil; 

{ Here we construct an outer-scope stack entry. This is needed 
to hold any pre-defined names. The distributed version does not 
include any of these, but they are easily provided. See the 
outlines in the code marked with *** if you want this feature. } 
new( stack) ; 
with stack! do begin 

current := nil; 

scopetree := nil; 

sub stack := nil 
end; 

printflag := false; 

uppercase := [ 'A' , 'B' , 'C ' , 'D ' , 'E ' , 'F' , 'G ' , 'H' , 'I ' , ' J' , 'K' , 'L ' , 'M' , 
'N','0','P','Q','R','S','T','U' ,'V ,'W ,'X' ,'Y','Z']; 
alphabet := uppercase + 

['a' ,'b' ,'c' ,'d' ,'e' ,'f' ,'g' ,'h' ,'i' ,' j' ,'k« ,'1' ,'m' , 
'n' ,'o' ,'p' ,'q' ,'r' ,'s' ,'t' ,'u' ,'v' ,'w' ,'x' ,'y' ,'z']; 
digits := ['0 ','T, '2', '3 ','4 ','5' ,'6 ','7 ','8 ','9']; 
alphanums := alphabet + digits { *** + ['__'] *** } ; 
usefulchars := alphabet + digits + 

['(', ')', '(', ',', ':', ';', ""]; 



0963 
0964 
0965 
0966 
0967 
0968 
0969 
0970 
0971 
0972 
0973 
0974 
0975 
0976 
0977 
0978 
0979 
0980 
0981 
0982 
0983 
0984 
0985 
0986 
0987 
0988 
0989 
0990 
0991 
0992 
0993 
0994 
0995 
0996 
0997 
0998 
0999 
1000 
1001 
1002 

1003 
1004 
1005 
1006 
1007 
1008 
1009 
1010 
1011 
1012 
1013 
1014 
1015 
1016 
1017 
1018 
1019 
1020 
1021 
1022 
1023 
1024 
1025 
1026 
1027 end 



namesperline := (LineWidth - (SigCharLimit + 21)) div 
(SigCharLimit +1); 

{ *#* if you W ant to introduce some options, this is the place 
to insert the call to your OptionAnalyser . None is provided 
with the standard tool because the requirements vary widely 
across user environments. The probable options that might be 
provided are (a) whether pre-declared names should appear in 
the call lists, (b) how many columns are to be printed in them 
(namesperline), (c) whether underscore is permitted in identifiers, 
and perhaps whether output should be completely in upper-case 
letters. The first option (a) requires a call to BuildPreDe fined 
just below this point, after analysing options... } 

total := 0; 

chno : = ; 

lineno := 0; 

level := -1 ; 

error flag := false; 

{ «** BuildPreDe fined; *** } 

{ *** page(output); *** } 
PrintHeading; 

writelnC output , ' Line Program/procedure/function heading'); 
for pretty := 1 to 43 do 
write (output, '-'); 
writelnC output); 
writelnC output) ; 

{ Now we need to get the first token, which should be program. } 
NextToken; 
if token <> NameSy then 

ErrorO) 
else if symbol <> Sprogram then 

ErrorO) 
else begin 

ProcessUnit (true) ; 

{ Having returned, there ought to be a period here. } 

if not errorflag then begin 

{ We check all tokens that begin with a period because 
what occurs after the Closing period is noting to do 
with us, } 

if (token <> PeriodSy) and (token <> SubRangeSv) then 
Error(4) 



else begin 

adjustment 
PrintLine 

end 



:= First; 



end 



end; 

{ Completed Phase One - now for the next, } 
if not errorflag then begin 
page (output) ; 
PrintHeading; 
writeln( output , 

' Head Body Notes ' , 
' ': SigCharLimit, 
' Calls made to' ); 
for pretty := 1 to (SigCharLimit+37) do 

write (output , '-'); 
writeln(output); 
PrintTree( superroot) ; 
writeln( output) 
end 
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AN OVERVIEW OF MAP 



MAP provides four basic additions to Pascal: constant expression 
e.aluation; source file inclusion; parameterized Macro substitution; and 
conditional compilation. This section contains a discussion of each f these 
facilities. 

MAP evaluates constant expressions (expressions where operands are 
constants or previously defined symbolic constants) on the right-hand side of 
CONST de «.. ations. Expressions may contain the following operators (listed in 
descending precedence): 



function: 

negating: 

multiplying: 

adding: 

relating: 

concatenating: 



name (arguments) 

NOT - 

AND * / DIV MOD MIN MAX 

OR ♦ - 

(one or more blanks) 



All standard operators have the same meaning as in Pascal, and strong typing is 
observed. The operators MIN and MAX require operands of type INTE6ER or REAL 
and return the smaller and larger of their operands, respectively. 
Concatenation requires operands of type PACKED ARRAY OF CHAR, and returns a 
PACKED ARRAY OF CHAR which is thw-ir concatenation (the type CHAR is assumed to 
be a packed array of one character for concatenation). 

MAP recognizes the standard Pascal functions ABS, SQR, CHR, ORD, ROUND, 
TRUNC, as well as two nonstandard functions, LENGTH and STRINGOF. LENGTH 
requires an argument of type PACKED ARRAY OF CHAR or CHAR, and returns the 
number of characters in it. STRINGOF requires an integer argument, and returns 
a PACKED ARRAY OF CHAR consisting of its decimal representation. 

Operands in CONST expressions may be constants or previously defined CONST 
names. Of course, Pascal scope rules apply to defined names. MAP also provides 
several predefined symbolic constants which can be used in CONST expressions. 
Two especially useful predefined names, TIME and DATE, give the time and date on 
which the compilation was performed. These predefined constants help when 
writ in* production programs that must be time and date stamped. For example, in 
a production program a heading is usually printed whenever the program runs: 

'PROGRAM XYZ COMPILED ON mm/dd/yy AT hh:mm:ss' 

Such a heading may provide the only link between an object version .f a program 
and its source. Unfortunately, a programmer may fail to update the heading when 
making changes to the program. Using the predefined constants in NAP to create 
the heading relieves the programmer of the updating task and guarantees the 
heading will always re accurate: 

CONST 

READING = 'PR06RAH XYZ COMPILED ON' DATE 'AT' TIME; 



In addition to constant expression evaluation, MAP supplies a macro 
substitution facility. A macro, which may have zero or more formal parameters, 
may be defined anywhere in the source program using the syntax: 

$DEFINE(name(formals),value) 

where 'name' is a valid Pascal identifier, 'formats' is a list of identifiers 
separated by commas, and 'value' is a sequence of Pascal tokens which is well 
balanced with respect to parentheses. Once a macro has been defined, it can be 
called by coding 

$name(actuals) 

where 'name' is the name of the macro, and 'actuals' is a list of actual 
parameters separated by commas. Each actual parameter must be a sequence of 
Pascal tokens which is well balanced with respect to parentheses. 

In addition to the user-defined macros, MAP recognizes several system 

macros. Definition of a new macro, as shown above, requires the use of the one 

such system macro, DEFINE. Another system macro, INCLUDE, provides for source 
file inclusion. When MAP encounters a call: 

$INCLUDE(file name) 

it opens the named file, and continues processing, reading input from the new 
file. Upon encountding an end-of-file condition, MAP closes the included file, 
and resumes processing the orig-taal file. Includes may be nested, but they may 
not be recursive (even though there is a way to prevent an infinite recursion). 

One may think of 'include' as a macro whose body is an entire file. This 
view, however, does not reflect the fact that the user also expects included 
text to be listed like standard input rather than like the body of a macro. 
While macro expansions are ..ot usually displayed in the source listing, included 
files are. Therefore, INCLUDE has a special status among macros. 



One other system macro, CODEIF, is provided 
compilation of code. The syntax of CODEIF is: 



to support the conditional 



$CODEIF(constant Boolean expression,code) 

where the constant Boolean exp. ession follows the rules for CONST expressions 
outlined above, and code represents a sequence of Pascal tokens which is well 
balanced with respect to parentheses. If the Boolean expression evaluates to 
'true 1 , the code is compiled; if the expression evaluates to 'false', the code 
is skipped. 

REFERENCE 
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1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
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29 
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32 
33 
34 
35 
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37 
38 
39 
40 
41 
42 
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44 
45 
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48 
49 
50 
51 
52 
53 
54 
55 
56 
57 
58 
59 
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61 
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65 
66 
67 
68 
69 
70 
71 
72 
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74 
75 
76 
77 
78 
79 
80 
81 
82 
83 
84 
85 
86 
87 
88 
89 
90 
91 
92 
93 
94 
95 
96 
97 
98 
99 
100 
101 
102 
103 
104 
105 
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107 
108 
109 
110 



program map(output, psource); 



portable version 



******************************************************************* 



program 



date : 



MAP (Macro Pascal) — Pascal preprocessor with 
constant expressions, macros, included files, and 
conditional compilation, (portable version) 

February 12, 1978, modified April 30, 1979 



programmer : Doug Comer, Computer Science Department, Purdue 



input 



output 



system : 
Copyright 



A Pascal program with expressions allowed in the 
const values, and macro definitions and calls. 
Macros may be called from the source code by 
writing the name prefixed with a dollar sign, with 
actual parameters supplied as a string 
enclosed in parentheses. The actual parameters 
may not contain references to other actual 
parameters or macros. Formal parameter references, 
also denoted by $name in the body of the macro, 
override macro definitions, so a macro with formal 
•a' cannot call macro 'a'. Null argument lists 
like () must be used when calling a macro with no 
actual parameters. Null parameters will be used 
if insufficient actual parameters are specified; 
extra actuals are ignored. Note that this differs 
from the version cited in the paper. 
Input must be in columns 1 - 're' (default 72) . 

Output is the file, psource, a compressed version 
of the Pascal source deck. The present version 
strips all comments except * (*$' and all the 
unnecesary blanks in performing the compression. 
Also, the source is crammed into 'pre' columns, 
the default being 71. 

Pascal on CDC 6500, Purdue dual MACE 

(C) 1978. Permission to copy, modify and 
distribute, but not for profit, is hereby granted, 
provided that this note is included. 



******************************************************************** 



label 1 



for aborting }; 



const 
arrow 
blank 
break 
comma 
defexpr 
deflist 
defprc 
defrc 
dollar 
double 
equal 
errflag = ■ 
errprefix = • — > error 
errlen = 40; 



S I I . 

■ true; 
s true; 
= 71; 
s 72; 
= •$.. 

= '0'; 



{ 



error messages 



} 



erabstype s 
erarith = 
eratntype = 
erbodyeof s 
erchrtype - 
ercklpar = 
erckrpar * 
ercodcom = 
ercodeof s 
ercodtype = 
erconvert s 
ercostype - 
erdefcom = 
erdefname - 
erexptype ~ 
erextype « 
erfacrpar = 
erfactype = 
erincname - 
erincrpar = 
erindrpar = 
erindxtyp = 
erlentype = 
erlntype = 
erlongstr = 
ermacname = 
ermacdefn = 
ermconsyn = 
eroctdig = 
eroddtype = 
eropen = 
eropttype = 
erordarg = 
erordtype = 
erover = 
erparscon - 
erparsend = 
erparseof = 
erparsfwd = 
erparsmcon= 
erpconsyn = 
erputtok = 
errelatyp = 
errelconf = 



'evalabs 

•arith 

'evalatn 

■get body 

•evalchr 

'ckmacro 

'ckmacro 

'do code if 

'do code if 

'do code if 

•convert 

'evalcos 

'dodefine 

'dodefine 

'expression 

'evalexp 

•factor 

•factor 

•do include 

'doinclude 

'do index 

'do index 

'evallen 

•evalln 

■gettok 

'gettok 

•getbsu 

•parsemcon 

'gettok 

'evalodd 

'open 

'dooptions 

'evalord 

'evalord 

•over 

'parsecon 

•parse 

■parse 

■parse 

•parsemcon 

'parsecon 

'puttok 

■relate 

'relate 



{ pointer for errors } 

{ break between re and rest of line } 

{ default is expression evaluation } 

{ default is listing } 

{ default right column for pascal } 

{ default right column for map input } 

{ double space carriage control } 



{ length of error message } 



type error, number needed 
bad type 

type error, number needed 
end of file in macro body 
type error, integer needed 
left paren expected 
right paren expected 
syntax error, missing comma 
unexpected end of file 
type error, boolean needed 
integer truncated 
type error, number needed 
missing comma 
syntax error, name needed 
invalid operand type 
type error, number needed 
right paren expected 
type conflict 
file name needed 
right paren expected 
right paren expected 
type error, integer needed 
type error, string needed 
type error, number needed 
string exceeds source line 
illegal macro name 
undefined macro call 
semicolon expected 
illegal octal digit 
type error, integer needed 
recursive includes ignored 
error in options list 
ord requires 1 char. arg. 
type error, char, needed 
table overflow 
equal sign needed 
unmatched end 
unexpected end of file 
unmatched forward decl. 
equal sign needed 
semicolon expected 
token too large 
illegal type for rel. oper. 
type conflict in relation 



111 
112 
113 
114 
115 
116 
117 
118 
119 
120 
121 
122 
123 
124 
125 
126 
127 
128 
129 
130 
131 
132 
133 
134 
135 
136 
137 
138 
139 
140 
141 
142 
143 
144 
145 
146 
147 
148 
149 
150 
151 
152 
153 
154 
155 
156 
157 
158 
159 
160 
161 
162 
163 
164 
165 
166 
167 
168 
169 type 



erroutype : 
ersintype : 
ersqrtype : 
erstrtype : 
ersyslpar : 
ertermtyp : 
ertrutype : 
ervalexp = 
ervarfnet = 
ervarrpar : 

greater 
inname 
inlname : 

letterb 
lettere 

Iparen : 

maxcalls = 
maxcons 

maxcol = 

maxestr = 

maxdefs : 

maxdefstr : 

maxfiles : 

maxfns : 

maxkeys = 

max line = 

mincol : 
minus 

ndefconst s 
{} newline 

newpage = 

nsysmac - 

pagesize = 

period = 

plus = 

quote = 

rparen = 

semi = 

space = 

star = 

sysinc = 

syscodeif = 

sys index = 

sysdefine = 

sysoption = 
titlel 
titlela 

titlelb = 
title2 

title3 = 

title4 = 

title5 = 

title6 = 

zero = 



'evalrou 

'evalsin 

'evalsqr 

'evalstr 

'dosysmac 

'term 

'evaltru 

•variable 

'variable 

'variable 



170 
171 
172 
173 
174 
175 
176 
177 
178 
179 
180 
181 
182 
183 
184 
185 
186 
187 
188 
189 
190 
191 
192 
193 
194 
195 
196 
197 
198 
199 
200 
201 
202 
203 
204 
205 
206 
207 
208 
209 
210 
211 
212 
213 
214 
215 
216 
217 
218 
219 
220 



alfa 
text 

crng 

csrng 

drng 

dsrng 

f Irng 

fnrng 

krng 

Inrng 

mrng 

pgrng 

msg 

fptr 



fns 



' 'B'; 

: ,£.. 

• •(•; 

• 15; 

■ 200; 
■■ 120; 
1000; 
= 100; 
4000; 

5; 
= 14; 
■■ 21; 

• 140; 
■■ 70; 

■ i— • . 

/ 

9; 
= chr 

■ M«; 

5; 
; 55; 



•)•; 



•*•; 

1; 
2; 
3; 
4; 
5; 

'MAP 
at '; 



- type error, real needed 

- type error, number needed 

- type error, number needed 

- type error, integer needed 

- left paren expected 

- invalid operand type 

- type error, real needed 

- value or name expected 

- unknown function, used 

- right paren expected 



{ standard input file name } 

{ standard input file name for } 

{ listing } 



max macro call depth } 

max active const defns } 

max right column for input/output 

max const string area } 

max defined macros } 

max macro string area } 

max included file depth } 

max recognized functions } 

max recognized language keywords } 

max characters per input line } 

min right column for input/output 

number of predefined constants } 
(10); { set to newline character } 
newpage carriage control } 
number of system macros } 
lines/page not counting heading } 



{ single space carriage control } 
{ codes for system macros } 



(vers 2. Op of 4/30/29) 
run on '; 



include pascal'; 
line file line line 



0'; 



packed array [1.. 103 of char; 
file of char; 



0.. maxcons; 
0.. maxestr; 
0.. maxdefs; 
0.. maxdefstr; 
0. .maxfiles; 
0.. maxfns; 
0.. maxkeys; 
0..maxline; 
0. .maxcalls; 
0.. pagesize; 



constant expression stack 
constant expr. string area 
macro definition stack 
macro def . string area 
included file stack 
builtin functions 
keywords 
input line 
macro call stack 
listing page 



packed arrayC 1..4Q3 of char; 
"formal; 



record 

Tname : alfa; 
fnext : fptr 
end; 



{ name of formal parameter } 



(fabs,fatn,fchr,fcos,fexp, { builtin functions } 
f len,f ln,fodd,ford,frou,fsin,fsqr,fstr,ftru); 

(lexadd,lexsub, { order dependent } 
lexand, lexmu It, lexdvd, lexmi n, lexmax, lexdi v, lexmod, 
lexalpha,lexint,lexreal,lexst,lexmac, 
lexbeg,lexcas,lexend,lexrec,lexfun,lexproc,lexcon, 
lexmcon, 

lextpe,lexvar,lexfwd, 
lexor,lexnot, 

lexlt,lexle,lexeq,lexgt,lexge,lexne, 
lexsemi,lexother, 
lex Iparen, I exrparen, 
lexcomma,lexeof); 



arg; 



{ actual argument list node } 



aform : 


alfa; { 


formal name 


afirst 


: dsrng; { 


start of actual in dstr 


alast : 


dsrng; 




anext : 


aptr 




end; 







constyp = (tbl,tch,terr,tin,tot,tre); { type of const expression 
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221 
222 
223 
224 
225 
226 
227 
228 
229 
230 
231 
232 
233 
234 
235 
236 
237 
238 
239 
240 
241 
242 
243 
244 
245 
246 
247 
248 
249 
250 
251 
252 
253 
254 
255 
256 
257 
258 
259 
260 
261 
262 
263 
264 
265 
266 
267 
268 
269 
270 
271 
272 
273 
274 
275 
276 
277 
278 
279 
280 
281 
282 
283 
284 
285 
286 
287 
288 
289 
290 
291 
292 
293 
294 
295 
296 
297 
298 
299 
300 
301 
302 
303 
304 
305 
306 
307 
308 
309 
310 
311 
312 
313 
314 
315 
316 
317 
318 
319 
320 
321 
322 
323 
324 
325 
326 
327 
328 
329 
330 



cset 

strng 

errmsg 

r_ 
ctab 



s set £t const yP/ 

* array Clnrng3 of char; 

= packed array C1..errlen3 of char; 



ctop, 
c valid 



cstr 
estop 



fstack 



ftop 
keywd 



mtop 
defs 



dtop 

defstr 

dstop 

atop 

funct 



inline 

last, 

next 

ch 

line 

pline 

tine, 
dte 
timein 
tottme 

linectr 
nerrors 

psource, 
dummy 

rcopt, 
prcopt 
listopt 
expropt 

lastlex 
outpos 

lexstr 
lexlen 
lextyp 

index 

conf I 



constant table } 



array Ccrng] of 
record 

cname : alfa; 
case ctyp : constyp of_ 
tin : (ci : integer); 
tre : (cr : real); 

tch : (cfirst : csrng; clen : csrng); 
tbl : (cb : boolean); 
tot : (co : alfa) 
end; 

1 current top of ctab and last const } 
crng; { last nontemporary constant } 

array Ccsrng3 of char;{ string const storage } 
csrng; 



{ included file stack } 



array Cf lrng3 of 
record 

alfa; { file name 

text; 

integer 



fname 
ffile 
fline 
end; 
-L.maxfil 



es; 

array CQ,.maxkeys3 of { language keywords } 
record 

Rnime : alfa; { keyword name } 

klex : lex 

end; 

array Cm rng3 of { macro calls } 
record 

margs : aptr; { list of arguments } 

mnext : dsrng; { next char to read } 

mlast : dsrng; { last char in this macro } 

matop : dsrng { actual top upon call } 
end; 

mrng; { top of called macro stack } 

{ macro definitions } 



: array Cdrng3 of 
record 

dname : alfa; { macro name } 

dfirst: dsrng; { first char in this macro } 

dlast : dsrng; { last char in this macro } 

dargs : fptr { list of formals } 

end; 

: drng; 

: array CdsrngJ of char; ( macro definition bodies } 

: dsrng; { top of definition string area } 

: dsrng; { actual arguments saved in top of defstr } 

: array Cfnrng3 of { list of builtin functions } 
record 

?nnme : alfa; { function name } 

fntyp : fns 

end; 

: strng; { input line } 

: Inrng; { last char and next char in inline } 

: char; { next character from getch } 

: integer; { last line number } 

: integer; { next pascal output line number } 

{ time of day from system } 

: alfa; { date from system } 

: integer; { clock value at start of run } 

: integer; { total time used in ms } 

: integer; { lines so far on this page } 
: integer; { number of errors found } 

: text; { dummy used for real number conversion } 



: Inrng; { right column on input/output } 

: boolean; { list on or off } 

: boolean; { recognize expressions on or off } 

: lex; { last token type put by puttok } 

: Inrng; { last column pos used by puttok } 

: strng; { lexical string } 

: Inrng; { number of chars in lexstr } 

: lex; { type of token in lexstr } 



integer; { for $ index macro } 
set of lex; 



{ set of tokens needing blank between } 

{ forward declarations for all procedures and functions } 

procedure arith; forward; 
procedure ckformaKname: alfa; { formal name } var found: boolean); 
forward; 
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procedure ckmacroCname: alfa; { macro name } var found: boolean); 
forward; 
procedure close; forward; 
procedure convrt; forward; 
procedure convrti; forward; 
procedure" convrtr; forward; 
procedure convrts; forward; 
procedure docodeif; forward; 
procedure dodef ine; forward; 
procedure doinclude; forward; 
procedure doindex; forward; 
procedure dooptions; forward; 

procedure" dosysmac(d: drng); { which macro } forward; 
procedure" errorCerr: errmsg); forward; 
procedure evalfns(f : fns); forward; 
procedure evalabs; forward; 



forward; 
forward; 
forward; 
forward; 
forward; 
forward; 
forward; 
forward; 
forward; 
forward; 
forward; 
forward; 
forward; 



forward; 



forward; 



forward; 



procedure" evalatn; 

procedure evalchr; 

procedure evalcos; 

procedure evalexp; 

procedure evallen; 

procedure evalln; 

procedure evalodd; 

procedure evalord; 

procedure" evalrou; 

procedure" evalsin; 

procedure evalsqr; 

procedure" evalstr; 

procedure evaltru; 

procedure experrorCerr: errmsg); 

procedure expression; forward; 

procedure factor; forward; 

procedure f indconCname: alfa; 
{ name of const } var found: boolean); 

procedure f lookup(name: alfa; 
{ function name } var fun: fns; 
{ function code } var found: boolean); 

procedure flush; forward; 

procedure forcereal; forward; 

procedure getactuals(f : fptr; 

{ pointer to next formal } var act: aptr); { pointer to actual } 
forward; 

procedure getbody; forward; 

procedure getbsu; forward; 

procedure getedparm; forward; 

procedure" getch; forward; 

procedure" getformalsCvar f : fptr); forward; 

procedure getkey; forward; 

procedure get I ine; forward; 

procedure getparm; forward; 

procedure gettok; forward; 

procedure initialize; forward; 

procedure needd: pgrng); forward; 

procedure newpg; forward; 

procedure open(name: alfa); { file name to open } 

procedure over(i: integer; 
{ current value } maxval: integer); { max value 

procedure parse(top: crng; 
{ ctop upon entry } tok: lex); { 
forward; 

procedure parsecon; forward; 

procedure" parsemcon; forward; 

procedure pushback; forward; 

procedure puttok; forward; 

procedure relate; forward; 

procedure scanheader; forward; 

procedure" term; forward; 

procedure terminate; forward; 

procedure timedate; forward; 

funct ion~ typesmatch: boolean; forward; 

function typeis(c: cset): boolean; forward; 

procedure variable; forward; 

{ procedures and functions } 



{ ******** j 

{ arith - recognize arithmetic ops in expression 

{ ******** } 

procedure arith; 



forward; 
} forward; 
token causing recursion } 



var 



op: lex; 



begin 
term; 

if (lextyp J_n Clexor, lexadd, lexsubD) and (not typeis(Cterr3)) 
tfien 

if ((lextyp = lexor) and typeis(CtbU)) or ((lextyp jn^ Clexadd, 

lexsubil) and typeis(Ctin, tre3)) 
then 



over(ctop / maxcons); 

while lextyp jn. Clexor, lexadd, lexsubil do 
begin 
ctop := ctop +1; op := lextyp; getkey; term; 
if (op = lexor) and typeis(CtbU) 

then with ctabCctop - 13 do cb := cb or ctabCctopD.cb 
else 
IT (op vn Clexadd, lexsub3) and typeis(Ctin, tre3) 
then 
with ctabCctop - 13 do 

if (ctyp = tin) and (ctabCctop3.ctyp = tin) 
then 

case op of 

lexadd: ci := ci + ctabCctop3.ci; 
lexsub: ci := ci - ctabCctop3.ci 
end { case } 
else 
begin 
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forcereal; 

case op of 

Texadd: cr := cr 
lexsub: cr := cr 

end { case } 



ctabCctop]. cr; 
ctabCctop]. cr 



else 



end { 



ctop 
end 
end 
arith }; 



_ ctabCctop]. ctyp <> terr 
:= ctop - 1 



then experror(erarith); 



t ******** j 

{ ckformal - if reference to formal, push on call stack } 
{ ******** } 

procedure ckformal { name:alfa; var found tboolean }; 



aptr; 



begin 

found := false; 
if mtop > 
Then 
Begin 

a := mstackCmtop], margs; 

while (a <> nil) and (not found) do 



begin 
~wit> 



end 



a* do 

aform = name 
tBen 
begin 

found := true; pushback, 
with mstackCmtop] do 
Begin 

margs := nil; 
mat op := atop 
end; 
getch 
end; 
a :* a".anext 
end; 
if found then gettok 
end 
1 ckformal }; 



mtop : s mtop +1; 



mnext := afirst; mlast := alast; 



{ ******** } 

{ ckmacro - if macro called, push onto stack } 
{ ******** } 

procedure ckmacro { name:alfa; var found:boolean }; 



var 



d: drng { index to defined macros }; 



begin 
d := dtop; defsCOD.dname := name; 
while defsCdD.dname <> name do d := d - 1; 
3TT~> ~" 

then 
Begin 

found := true; 

if d <= nsysmac then dosysmac(d) 
else 
Begin 

over (mtop, maxcalls); 
with mstackCmtop + 1], defsCd] do 
Begin 

margs ;= nil; mnext := dfirst; mlast := dlast; 

matop := atop; while ch = blank do getch; 

j_f ch = Iparen 

then 

"""Begin 

getch; getactuals(dargs, margs); 
if ch <> rparen then error(erckrpar) 
end 
else error(ercklpar) 
end; 
mtop := mtop +1; getch 
end; 
gettok 
end 
end 1 ckmacro } ; 

• ******** i 

close - close the current file + restore old one } 

; ******** \ 



procedure close; 
begin ftop := ftop - 1 end { 



close 



{ ******** \ 

{ convrt - convert constant to pascal input format 
{ ******** i 

procedure convrt; 



integer; 

char; 

boolean; 



with ctabCctop] do 
case ctyp of 
tin: 
begin 

if abs(ci) >= maxint 

TFen begin i : = maxint; error(erconvert) end 

else i := ci; 

if i < then begin sign := true; i := abs(i) end 
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else sign := false; 
lexlen := 0; 
while i > do 
begin 

Lexlen := lexlen +1; 

lexstrClexlen] := chr(ordCO') + (i mod 10)); 
i := i div_ 10 
end; 
if sign then 

begin lexlen := lexlen + 1; lexstrClexlen] :* minus end; 
for i := 1 to( lexlen div 2) do 
begin 
c := lexstrCi]; LexstrCi] := lexstrClexlen — i + 13; 
lexstrClexlen - i + 13 :- c 
end; 
lextyp := lexint 
end; 
terr:; 
tot: 
begin 

lexlen := 10; unpack(co, lexstr, 1); lextyp := lexalpha; 
while lexstrClexlen} » blank do lexlen := lexlen - 1 
end; 
tch: 
begin 

lextyp := lexst; lexlen :* 1; lexstrCl] :* quote; 
for i := to clen - 1 do 
begin 

lexlen := lexlen + 1; 
lexstrClexlen] := cstrCcfirst + 13; 
if lexstrClexlen] - quote then 
begin lexlen := lexlen + 1; lexstrClexlen!! : s quote 
end 
end; 
lexlen : s lexlen +1; lexstrClexlen] :* quote 
end; 
tbTT" 
begin 

lextyp := lexalpha; 

2± cb 

then begin unpackCTRUE 1 , lexstr, 1); lexlen := 4 end 
else begin unpack ('FALSE', lexstr, 1); lexlen :« 5 end 
erup 
tre: 
begin 

rewrite(dummy); write(dummy, cr, blank); reset (dummy); 
whi le dummy" = blank do get (dummy); lexlen := 0; 
while dummy" <> blank~5b 
begin 

lexlen := lexlen + 1; lexstrClexlen] : s dummy"; 
get (dummy) 
end; 
lextyp := lexreal 
end 
end 1 case } 
end "I convr t } ; 

******** } 

convrti - convert integer token to binary form } 
******** j 

procedure convrti; 



i: integer; 
I: Inrng; 

begin 
with ctabCctop] do 
begin 

ctyp := tin; ci := 0; 
for I := 1 to lexlen do 
ci := 10 * ci + ord(lexstrCU) - ord(zero) 
end 
end I convrti }; 

******** j 

convrtr - convert real token to binary form } 
******** j 

procedure convrtr; 



var 



Inrng; 



begin 

rewrite(dummy); for i := 1 t£ lexlen d£ write(dummy, LexstrCi]); 

write(dummy, blank); reset (dummy); 

with ctabCctop] do begin ctyp := tre; readCdummy, cr) end 
endT" convrtr }; 

******** j 

convr ts - convert quoted string to const string } 
******** } 

procedure convrts; 



var 



I: Inrng; 



begin 
with ctabCctop] do 
begin 

ctyp := tch; clen := 0; cfirst := estop + 1; 
I := 2 { skip leading quote }; 
whi le I <= (lexlen - 1) do 
begin 

clen := clen + 1; over(cstop, maxestr); 
estop := estop + 1; cstrCcstop] := lexstrCl]; 
vf lexstrCl] = quote then I := I + 2 else I := I + 1 
end 
end 
end J convrts }; 
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{ ******** } 

{ docodeif - process $codeif( expr. 
{ ******** j 

procedure docodeif; 



code) } 



a: 
ctr: 



dsrng { save area for atop upon entry }; 
integer { left paren count }; 



ctop ♦ 1; 



getkey; over(ctop, maxcons); ctop 
ctop : s ctop - 1; a := atop; 
if Lextyp <> lexcomma then experror(ercodcom) 
else 
wTth ctabCctop + 13 do 
iT ctyp - tbl 
TFen 
TT cb 
TFen 
begin 
overdntop, maxcalls); 
with mstackCmtop + 13 do 



expression; 



begin 



nil; 
atop; 



mlast := atop 
raatop := a; 



1; getcdparm; 



getch 



newline 



0) and (ftop = 0) and eof (fstackC03. 



- 1 
ctr 



margs 
mnext 
end; 
ratop := mtop + 1, 
end 
else 
begin 
ctr := 1; 
while ctr > do 
begin 

2F ch 
then 
Begin 
vf_ (mtop 
ffile) 
then begin error(ercodeof); 
encT 
else 

TT ch = rparen then ctr : = ctr 
eTse if ch = Iparen then ctr : ; 
getch 
end 
end 
else if ctyp <> terr then error(ercodtype) 
end ( "aocoae"if } ; 

{ ******** j 

{ dodefine - process $define (name (formal parms) f string) } 
{ ******** j 

procedure dodefine; 

begin 
gettok; 

if lextyp <> lexalpha 
else 
begin 

over (dt op, maxdefs); 
with def sCdtop3 do 
begin 

TexstrC03 := dollar; 

dfirst := dstop + 1; 

if lextyp = lex Iparen 

TFen begin gettok; getformals(dargs); gettok end 

else dargs := nil 



then error(erdefname) 



dtop := dtop +1; 



packdexstr, 0, dname); 
dlast := dstop; gettok; 



if lextyp <> lexcomma 
TFen begin error(erdefcom); 
"else get body 
enci 
end T~dodef ine }; 

{ do include - process $ include (file) 
{ ******** } 

procedure doinclude; 



dtop := dtop - 1 end 



name: alfa; 



begin 



getbsu; 

if lextyp <> lexalpha 

else 



then error(erincname) 



end 



packdexstr, 1, name) { check file name here if desired }; 

getkey; vf_ lextyp <> lexrparen then error(erincrpar); 

open (name) 
end 
1 doinclude } ; 



******** i 

do index - process $ index (expression) 
******** j 



{ 
{ 
procedure doindex; 



Inrng; 



begin 



overCctop, maxcons); ctop := ctop + 1; getkey; 
if lextyp = lexrparen 

then with ctabCctop3 do begin ctyp := tin; ci := end 
else expression; 

if lextyp <> lexrparen then error(erindrpar) 
else 
Begin 
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pushback; 

with ctabCctop3 do 

if ncrt (ctyp in [terr, tin3) then error(erindxtyp) 
eTse 

TT ctyp = tin 
TFen 
begin 

TncTex := index + 1; ci := ci + index; convrt; 
overdntop, maxcalls); mtop := mtop + 1; 
with mstackCmtop3 do 
begin 
margs := ni I; mnext := atop; mlast : s atop - 1; 
matop :- atop; 
for i := lexlen downto 1 do 
begin 

mnext := mnext - 1; 
defstrCmnext3 := lexstrCi3 
end; 
getch 
end 
end 
end; 
ctop := ctop - 1 
end { doindex }; 

******** } 

dooptions - process $options(...) } 
******** j 

procedure dooptions; 



i: integer; 

begin 
gettok; 

while not (lextyp jn [lexrparen, lexeof3) do 
begin 

if lextyp - lexalpha 
then 

~~tT lexstr[13 jn ['R', 'P', 'N', 'L', 'E'3 
then 

case lexstr[13 of 
T«, 'R': 
begin 

while not (ch in ['0* .. '9', ') '3) do getch; 

T1^"0; 

while ch jn. ['0' .. '9'3 do 

begin i := 10 * i + ord(ch) - ord('O'); getch end; 
if (mincol <= i) and (i <= maxcol) then 
case lexstr[13 of 
r P"' : prcopt := i; 
'R': rcopt := i 
end { case } 
end; 



if lexlen >= 3 then 
i± lexstr[33 = 'L' 
else if lexstr[33 
'L': listopt := true; 
'E': expropt := true 
end 
else error(eropttype) 
else if lextyp <> lexcomma 
gettoF" 
end 
end 1 dooptions } ; 



then listopt := false 
'if then expropt := false; 



then error(eropttype); 



******** j 

dosysmac - perform proper system macro } 
******** } 

procedure dosysmac { d:drng }; 

begin 
gettok; 

if lextyp <> lexlparen then error(ersyslpar) 
eTse 

case d of 

sysinc: doinclude; 
syscodeif: docodeif; 
sysindex: doindex; 
sysdefine: dodefine; 
sysoption: dooptions 
end 
end { dosysmac }; 

******** \ 

error - write out error message } 
******** } 

procedure error { err:errmsg }; 



i: Inrng; 

begin 
need(2) { make sure message fits on page }; 
if listopt 
then 
begin 
write(space, errf lag); _for i := 1 to next - 1 do write(blank); 
writeln(arrow) 
end 
else writelnC AT LINE:', line: 2, ' (pascal line:', pline: 2, ')'); 
"wrTTe In (space, errprefix, err); nerrors := nerrors + 1 
end { error }; 

******** } 

evalfns - evaluate a builtin function } 
******** } 

procedure evalfns { f:fns }; 
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begin 
case f of 

fabs: evalabs; 

fatn: evalatn; 

fchr: evalchr; 

fcos: evalcos; 

fexp: evalexp; 

flen: evallen { length of a string }; 

fin: evalln; 

fodd: evalodd; 

ford: evalord; 

frou: evalrou { round }; 

fsin: evalsin; 

fsqr: evalsqr; 

fstr: evalstr { string of - make integer a string }; 

ftru: evaltru { truncate } 
end { case } 
end { evalfns }; 

{ ******** i 

{ evalabs - evaluate the abs builtin function } 
{ ******** j 

procedure evalabs; 

begin 
with ctabCctop] do 
TT typeisCCtre, tin]) 
tHen case ctyp of 

tin: ci :- aFsCci); 
tre: cr := abs(cr) 
end 
else experror(erabstype) 
end 1 evalabs }; 

{ evalatn - evaluate the arc tan builtin function } 
procedure evalatn; 



begin 
with ctabCctop] do 



typeisCCtre, tin]) 
TFen 

case ctyp of 
tTn: begin cr := arctan(ci); 
tre: cr :- arctan(cr) 
end { case } 
else experrorCeratntype) 
end 1 evalatn }; 



ctyp 



tre end; 



{ ******** } 

{ evalchr - evaluate the chr builtin function } 
{ ******** } 

procedure evalchr; 

var 

i: integer; 

begin 

with ctabCctop] do 
TT ctyp = tin 
TFen 
begin 

i :- ci; ctyp := tch; overCcstop, atop); 
estop := estop + 1; clen := 1; cstrCcstop] := chr(i); 
cfirst := estop 
end 
else experror(erchrtype) 
end T-evalchr } ; 

{ ******** j 

{ evalcos - evaluate the cosine builtin function } 
{ ******** } 

procedure evalcos; 

begin 
with ctabCctop] do 
if typeisCCtre, tin]) 
TFen 

case ctyp of 
tTn: begin cr :* cos(ci); ctyp := tre end; 
tre: cr := cos(cr) 
end { case } 
else experrorCercostype) 
end 1 evalcos } ; 

{ ******** j 

{ evalexp - evaluate the exp builtin function } 
j ******** \ 

procedure evalexp; 

begin 

with ctabCctop] do 
if typeisCCtre, tin]) 
then 

case ctyp of_ 

tin: begin cr := exp(ci); ctyp := tre end; 
tre: cr := exp(cr) 
end { case } 
else experror(erextype) 
end 1 evalexp } ; 

{ ******** \ 

{ evallen - evaluate the length builtin function } 
{ ******** j 
procedure evallen; 



var 



i: integer; 
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begin 

with ctabCctop] do 
if ctyp = tch 
TFen 
begin 

i := clen; estop := cfirst 
end 
else experror(erlentype) 
end 1 evallen } ; 



{ ******** j 

{ evalln - evaluate the In builtin function } 
| ******** j 

procedure evalln; 



begin 
with ctabCctop] do 
if typeisCCtre, tin]) 
then 

case ctyp of_ 
tin: begin cr := ln(ci); 
tre: cr := ln(cr) 
end { case } 
else experror(erlntype) 
end 1 evalln } ; 



1; ctyp := tin; 



ctyp := tre end; 



{ ******** } 

{ evalodd - evaluate the odd builtin function } 
{ ******** } 

procedure evalodd; 



i: integer; 

begin 
with ctabCctop] do 

if ctyp = tin 

TFen begin i := ci; ctyp := tbl; cb := odd(i) end 

else experror(eroddtype) 
end 1 evavodd } ; 

{ ******** j 

{ evalord - evaluate the ord builtin function } 
{ ******** j 

procedure evalord; 



c: char; 

begin 
with ctabCctop] do 
TT ctyp = tch 
TFen 

if clen = 1 

then begin c := cstrCcfirst]; ctyp := tin; ci : s ord(c) 
else experror(erordarg) 
else experror(erordtype) 
end I evalord }; 

{ ******** j 

{ evalrou - evaluate the round builtin function } 
{ ******** j 

procedure evalrou; 



r: real; 

begin 
with ctabCctop] do 

if ctyp = tre 

TFen begin r := cr; ctyp := tin; ci := round(r) end 

else experror(erroutype) 
end 1 evalrou }; 

{ ******** } 

{ evalsin - evaluate the sin builtin function } 
{ ******** j 

procedure evalsin; 

begin 
with ctabCctop] do 
TT typeisCCtre, tin]) 
TFen 

case ctyp of 

tTn: begin" cr := sin(ci); ctyp := tre end; 
tre: cr := sin(cr) 
end { case } 
else experror(ersintype) 
end 1 evals in } ; 

{ ******** j 

{ evalsqr - evaluate the sqr builtin function } 
{ ******** j 

procedure evalsqr; 

begin 

with ctabCctop] do 
if typeisCCtre, tin]) 
then 

case ctyp of_ 

tTn: ci := sqr(ci); 
tre: cr := sqr(cr) 
end { case } 
else experror(ersqrtype) 
end { evalsqr }; 

{ ******** \ 

{ evalstr - evaluate the stringof builtin function } 
[ ******** j 

procedure evalstr; 
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i: integer; 
c: char; 
sgn: boolean; 

begin 

with ctabCctop] do 

TT ctyp <> tin then experror(erstrtype) 
eTse 
Begin 
i := ci; 

if i < then begin sgn := true; i := abs(i) end 
eTse sgn := false; 

over(cstop, atop); estop := estop + 1; ctyp := tch; 
cfirst := estop; 

if i = then begin clen := 1; cstrCcstop] := zero end 
eTse 
begin 

clen := 0; 
while i > do 
begin 

cstrCcstop] := chr(ord(zero) + (i mod 10)); 
i := i div 10; over(cstop, atop); 
estop := estop + 1; clen := clen + 1 
end; 
if sgn then cstrCcstop] := minus 
eTse estop := estop - 1; 
for i := tcKclen - 1) div 2 do 
"Eegin 

c := cstrCi + cfirst]; 

cstrCi + cfirst] := cstrCcfirst + clen - i - 1]; 
cstrCcfirst + clen - i - 1] := c 
end 
end 
end 
end { evalstr }; 

{ ******** } 

{ evaltru - evaluate trunc builtin function } 
{ ******** j 

procedure evaltru; 



r: real; 

begin 
with ctabCctop] do 

TT ctyp = tre 

tFen begin r := cr; ctyp := tin; 

else experror(ertrutype) 
end J evaltru }; 

s ******** j 

{ experror - print error for expression and flush } 
j ******** } 

procedure experror { err:errmsg }; 

begin error(err); ctabCctop]. ctyp := terr; flush 
end { experror } ; 

{ ******** ] 

{ expression - parse expression; put value in ctab[ctop] } 
{ ******** j 
procedure expression; 

begin 
relate; 

if typeis(Ctch]) 
TFen 
begin 

over (ctop, maxcons); ctop := ctop + 1; 
whi le lextyp Jn_ Clexst, lexalpha] do 
begin 
relate; 

if typeis(CtchD) 

tTTen with ctabCctop - 1] do clen := clen + ctabCctop]. clen 
else if not typeis(Cterr]) then experror(erexptype) 
en3; 
ctop := ctop - 1; 
end 
end { expression }; 

t ******** j 

{ factor - recognize factor part of expression } 
{ ******** \ 

procedure factor; 



ci := trunc(r) end 



op: lex; 

begin 

if lextyp _jj2 Clexnot, lexsub] 
tTTen 
begin 

op := lextyp; getkey; factor; 
with ctabCctop] do 

if typeis(CtbU) and (op = lexnot) then cb := not cb 
else 

T7 typeis(Ctin, tre]) and (op = lexsub) 
tTTen 

case ctyp of_ 
tin: ci := - ci; 
tre: cr := - cr 
end { case } 
else 
TT ctyp <> terr 

then begin ctyp := terr; experror(erfactype) end 
end 
else 
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if lextyp = lexlparen 
then 
begin 
getkey; expression; 
if not typeis(Cterr]) then 
if lextyp <> lexrparen then experror(erfacrpar) 
eTse getkey 
end 
else variable 
end I Factor }; 

{ ******** j 

{ f indcon - find previously defined constant } 
r ******** j 

procedure f indcon { nameralfa; var found:boolean }; 



c: crng; 
i: integer; 

begin 

c := cvalid; ctabC0].cname :- name; 
while ctabCc].cname <> name do c := c - 1; 
rf_ c > 
then 
begin 

ctabCctop] := ctabCc]; 
with ctabCctop] do 
if ctyp = tch 
then 
begin 
over(cstop + clen, maxestr); cfirst := estop + 1; 
for i := ^o clen - 1 do 
begin 

estop := estop + 1; 

cstrCcstop] := cstrCctabCc]. cfirst + i] 
end 
end; 
found := true 
end 
end 1 f indcon }; 

{ ******** ] 

{ flookup - lookup function name and return type code } 
[ ******** j 
procedure flookup { name:alfa; var fun: fns; var found:boolean }; 



f: fnrng; 

begin 

funct CO] . f nnme := name; f := maxfns; 

while functCf].fnnme <> name do f := f - 1; 

_i_f f = then found := false 

else begin found := true; fun := funct Cf].fntyp end 
end { flookup } ; 

i ******** } 

{ flush - flush to semicolon } 
r ******** i 
procedure flush; 

begin while not (lextyp vn Clexeof, lexsemi]) do getkey 
end { flush }; 

{ ******** } 

{ forcereal - force top two constants on stack to real } 
i ******** \ 

procedure forcereal; 



i: integer; 

begin 
with ctabCctop] do 

TT ctyp = tin then begin i := ci; ctyp := tre; c 
with ctabCctop - 1] do 

if ctyp = tin then begin i := ci; ctyp := tre; c 
end T* forcereal }; 

i ******** j 

{ getactuals - get actual parameters for macro call } 
| ******** } 

procedure getactuals { f:fptr; var act:aptr }; 

begin 

if f = nil 

then { if no formals, then no actuals } 
else" 
begin 

new(act); 
with act", f" do 
begin 
aform := fname; alast := atop - 1; getparm; 
afirst := atop; rf_ ch = comma then getch; 
getactuals(fnext / anext) 
end 
end; 
end { getactuals } ; 

; ******** } 

{ getbody - get the body of a macro } 
£ ******** } 

procedure getbody; 



: s i end; 
:- i end 



ctr: integer { left parenthesis counter }; 



begin 

vf ch = rparen 
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then 
with def sUdtopD do 
Begin getch; "cTlast := dstop; dfirst := dstop + 1 end 
else 
Begin 

ctr := 1; 

with def stdtop] do 

^9 in 

whi Le ctr > do 
begin 
over (dstop, atop); dstop := dstop +1; 
defstrCdstop3 := ch; dlast := dstop; 
if ch = rparen then ctr := ctr - 1 
eTse 

if ch = Lparen then ctr := ctr + 1 

eTse 

vT (ch = newline) and (ftop = 0) and eof (fstackC03. 

ffile) 
then begin error(erbodyeof); goto 1 end; 
getcTT" 
end; 
defstrCdlastD := blank { replace trailing ")" } 
end 
end 
end 1 getbody }; 

{ ******** } 

{ getbsu - get basic syntatic unit, subst. macro calls } 
| ******** j 

procedure getbsu; 



name: alfa; 
found: boolean; 

begin 
gettok; 

whi le lextyp = lexmac do 
begin 
packdexstr, 1, name); 
if not found then 
begin 

ckmacro(name, found); 

if not found then begin error(ermacdefn); gettok end 
end; 
end 
end 1 getbsu }; 

{ ******** j 

{ getcdparm - get "codeif" code and save it } 
{ ******** i 

procedure getcdparm; 



ckformaKname, found); 



ctr: integer; 
d: dsrng; 

begin 
d := dstop; ctr := 0; 
whi le (ctr > 0) or (ch <> rparen) do 
begin 
over(d, atop); d := d + 1; defstrCdD := ch; 
if ch = lparen then ctr := ctr + 1 
eTse if ch = rparen then ctr := ctr - 1; 
getch 
end; 
if d > dstop then 
begin 

over(d, atop); d := d + 1; defstrCdD := blank; 
whi le d > dstop do 
begin 

atop := atop - 1; defstrCatop] : s defstrCdD; d := d - 1 
end 
end 
end 1 getcdparm }; 

{ ******** j 

{ getch - get next character and place in ch } 
{ ******** ] 
procedure getch; 

begin 

if mtop > then 
while (mstackCmtop3. mnext > mstackCmtopD.mlast) and (mtop > 0) do 
begin atop := mstackCmtop3.matop; mtop := mtop - 1; end; 
if mtop > 
then 

with mstackCmtopD do 
'Begin ch := defstrCmnextD; mnext := mnext + 1 end 
else 
Begin 

if next > last then getline; ch := inlineCnextD; 
next := next + 1 
end 
end { getch }; 

{ ******** j 

{ getformals - get formal parameter names } 
{ ******** j 

procedure getformals { var f:fptr }; 

begin 

if lextyp <> lexalpha then f := ni I 
eTse 
begin 

new(f); lexstrCOD := dollar; packdexstr, 0, f.fname); 

gettok; 

if lextyp - lexcomma 

TFen begin gettok; getformals(f.fnext) end 

else f .fnext := nil 
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end 
end { getformals }; 

{ ******** j 

{ getkey - get token and classify language keywords } 
r ******** i 

procedure getkey; 



name: alfa { name of constant }; 
k: krng { pointer to keywords }; 

begin 
getbsu; 

if lextyp = lexalpha 
TFen 
begin 
packdexstr, 1, name); keywdE03.kname := name; k :- maxkeys; 
while keywdCkD.kname <> name do k := k - 1; 
J_f k > then lextyp := keywdCk3.klex 
end 
end 1 getkey } ; 

i ******** \ 

{ getline - place input line in 1 inline; set next, last } 
[ ******** j 

procedure getline; 



incol: Inrng; 
i: integer; 

begin 
while eof (fstackCftop3. ffile) and (ftop > 0) do close; 
if eof (fstackCftopD.f file) 

then begin next := 1; last := 0; inlineCnext] := newline end 
else 
with fstackCftop3 do 
begin 

line := line + 1; fline := fline + 1; incol :- 1; 

if listopt 

then 

if linectr >= pagesize 
then begin linectr := 0; newpg end; 
linectr := linectr + 1; write(space, line: 4, ' '); 
for i := 1 to 7 do write(fnameCi3); 
write(fline: 5, pline: 8, • '); 

while (not eoln(ffile)) and (incol <■ rcopt) and (ffile* 
= blank) do 

begin get (ffile); write(blank); incol :* incol ♦ 1 
end; 
next := incol; 

inlineCnextD := newline { in case of empty line }- 
while ( not eoln(ffile)) and (incol <= rcopt) do 
begin 

inlineCincoU := ffile"; incol := incol + 1; 
write(ffile'); get(ffile) 
end; 
last := incol - 1; 
if not eoln(ffile) then 
^egin 

write(break); 

while not eoln(ffile) and (incol < maxcol) do 
begin write(ffile*); get (ffile) end 
end; 
writeln 
end 
else 
begin 

while ( not eoln(ffile)) and (incol <= rcopt) and (ffile* 
= blank) do 

begin getCTFile); incol z- incol + 1 end; 
next : s incol; 

inlineCnext] := newline { in case of empty line }; 
while ( not eoln(ffile)) and (incol <= rcopt) do 
~ Tegin 

inlineCincol] := ffile*; incol :* incol ♦ 1; 
get(ffile) 
end; 
last := incol - 1 
end; 
readln(ffile); 
if last >= next 

TFen begin last := last + 1; inlineClast] := newline end 
end 
end { getline }; 

t ******** j 

{ getparm - get an actual parm and save } 
^ ******** j 
procedure getparm; 



ctr: integer; 
d: dsrng; 

begin 

d := dstop; ctr := 0; 

whi le (ctr > 0) or not (ch vn Ccomma, rparen]) do 
begin 

over(d, atop); d := d + 1; defstrCd] := ch; 
if ch = lparen then ctr := ctr + 1 
else if ch = rparen then ctr := ctr - 1; 
getch 
end; 
if d > dstop 
then 
begin 

over(d, atop); d := d + 1; defstrCd] := blank; 
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defstrCd]; d := d - 1 



whi Le d > dstop do 
Begin { move parm to right } 

atop := atop - 1; defstrCatop] 
end 
end 
end 1 getparm }; 

{ ******** } 

{ gettok - get a token; set lexstr, lexlen, lextyp } 
[ ******** } 
procedure gettok; 



i: integer; 
num: integer { value of octal number }; 

begin 

texlen := 0; 
whi le lexlen = do 
begin 

while ch = blank do getch; lexlen := 1; lextyp := lexother; 
lexstrC13 := ch; 
case ch of 
newline: 

if (ftop = 0) and eof (fstackCftopD.ffile) 
"tFen lextyp := lexeof 
else begin getch; lexlen := end; 
*K r r r irr r C', '*', % *\ 'F', 'GT^', 'I', 'J', 'K', '!_', 
'M', 'N', '0', 'P', 'Q', 'R', 'S', 'T', 'U', 'V, 'W, 'X', 
'Y', 'Z': 
begin 

getch; lextyp := lexalpha; 
while ch in C'A' .. 'Z', '0' .. '9'] do 
begin 

lexlen := lexlen + 1; lexstrClexlen] :- ch; getch 
end; 
ifTexlen > 10 then lexlen := 10; 
Tor i := lexlen t 1 to 10 do lexstrCi] := blank 
end; 
'O^T'I', '2', '3', '4', '5', '6\, '7', '8', '9': 
begin 

getch; lextyp := lexint; 
while ch \n CO' .. '9'] do 
begin 

lexlen := lexlen + 1; lexstrClexlen] := ch; getch 
end; 
ifcF = letterb 
tFen 
Begin { octal } 
getch; num := 0; 
for i := 1 to lexlen do 
~Tf lexstrTD jn. CO" 1 ".. '7'] 

tFen num := 8 * num + orddexstrCi]) - ord(zero) 
else begin num := 8 * num; error(eroctdig) end; 
overCctop, maxcons); ctop := ctop + 1; 
with ctabCctop] do begin ctyp := tin; ci := num end; 
convrt; ctop := ctop - 1 
end 
else 
begin 
if ch 
THen 
begin 
getch; 

J_f ch = period then pushback 
else 
begin 

lextyp := lexreal; lexlen := lexlen + 1, 
lexstrClexlen] := period; 
while ch vn CO' .. '9'] do 
begin 



period 



lexlen := lexlen + 1; 
lexstrClexlen] := ch; 
end 



getch 



end; 
if ch = lettere 
then 
b^egin 

lextyp := lexreal; lexlen := lexlen + 1; 
lexstrClexlen] := ch; getch; 
if ch vn Cplus, minus] then 
begin 

lexlen := lexlen + 1; lexstrClexlen] := ch; 
getch 
end; 
while ch in CO" .. '9'] do 
begin 

Lexlen := lexlen + 1; lexstrClexlen] := ch; 
getch 
end 
end 
end 
end; 
'+': begin lextyp 
'-• : begin lextyp 
'*': begin lextyp 
'/*: begin lextyp 

begin 
getch; 

jj_ ch <> star 
else 
begin 
getch; 

if ch = dollar 
TFen 
begin 

TiTlen := 3; unpackC (*$', lexstr, 1); 
repeat 



lexadd; getch end; 

lexsub; getch end; 

lexmult; getch end; 

lexdvd; getch end; 



then lextyp := lexlparen 



1651 
1652 
1653 
1654 
1655 
1656 
1657 
1658 
1659 
1660 
1661 
1662 
1663 
1664 
1665 
1666 
1667 
1668 
1669 
1670 
1671 
1672 
1673 
1674 
1675 
1676 
1677 
1678 
1679 
1680 
1681 
1682 
1683 
1684 
1685 
1686 
1687 
1688 
1689 
1690 
1691 
1692 
1693 
1694 
1695 
1696 
1697 
1698 
1699 
1700 
1701 
1702 
1703 
1704 
1705 
1706 
1707 
1708 
1709 
1710 
1711 
1712 
1713 
1714 
1715 
1716 
1717 
1718 
1719 
1720 
1721 
1722 
1723 
1724 
1725 
1726 
1727 
1728 
1729 
1730 
1731 
1732 
1733 
1734 
1735 
1736 
1737 
1738 
1739 
1740 
1741 
1742 
1743 
1744 
1745 
1746 
1747 
1748 
1749 
1750 
1751 
1752 
1753 
1754 
1755 
1756 
1757 
1758 
1759 
1760 



repeat 
getch; lexlen := lexlen +1; 
lexstrClexlenD := ch 
until ch = star; 
getch; lexlen := lexlen ♦ 1; 
lexstrClexlen] : s ch 
until ch = rparen; 
getch 
end 
else 
begin 

lexlen := 0; 

repeat while ch <> star do getch; getch 
until ch = rparen; 
getch 
end 
end 



end; 



')': begin lextyp := lexrparen; 

begin 
getch; 

if not (ch jjni C'A' .. 'Z'D) 
then begin error (ermacname); 
else 



getch end; 



lexlen := end 



'V, '0' 



•9'3 do 



en< 



end; 



egin 
lextyp := lexmac; 
while ch in C'A' 
begin 

lexlen := lexlen ♦ 1; lexstrClexlen! :* ch; 
getch 
end; 
if lexlen > 10 then lexlen := 10; 
7or i := lexlen +"TTo 10 do lexstrCiD :* blank 
id"- — "" 



2; getch end 



"begin lextyp := lexeq; getch end; 
begin lextyp := lexcomma; getch end; 



begin 

getch; 

jf_ ch = period then 

begin lexstrC23 := period; lexlen 
end; 



begin { extract string including all quotes } 
lexlen := 0; 
repeat 
overClexlen, maxline); lexlen := lexlen + 1; 
lexstrClexlen] := ch; 
repeat 
getch; 

if ch = newline then 
begin 

error(erlongstr); pushback; 
ch := quote { supply missing quote } 
end; 
overClexlen, maxline); lexlen : s lexlen +1; 
lexstrClexlen] := ch 
unt i I lexstrClexlen] = quote; 
getch 
until ch <> quote; 
lextyp := lexst 
end; 



begin 

getch; 

J_f ch = equal 

then begin lexlen := 2; lexstrC2] := equal; getch end 
end; 



begin 

lextyp := lexne; 




begin 

lextyp := lexor; 

getch 
end; 



unpackCo', lexstr, 1); lexlen 



unpackCOR', lexstr, 1); lexlen : s 2; 



begin 

lextyp := lexand; unpack( 'AND', lexstr, 1); 

lexlen := 3; getch 
end; 



lexstrC2] := equal; lextyp := lexle; 




lexstrC2] := greater; 
; getch 



begin 
getch; 

if ch = equal 
then 
begin 

lexlen := 2; 



lextyp := lexge; lexstrC2] := equal; 
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1824 
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1831 
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1838 
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1864 
1865 
1866 
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1868 
1869 
1870 



getch 
end 
else Lextyp := Lexgt 



begin 

lextyp := lexle; unpack('< s ', lexstr, 1); lexlen := 2; 

getch 
end; 

, \' T T~ 

begin 

lextyp := Lexge; unpack('>=', lexstr, 1); Lexlen : = 2; 

getch 
end; 

begin 

lextyp := lexnot; unpackCNOT', lexstr, 1); 
lexlen := 3; getch 
end; 
';': begin lextyp := lexsemi; getch end; 
•C, '3 T , '*', '__', '?': getch { all oERer characters } 
end { case } 
en? 
end T"~gettok }; 



{ ******** } 

{ initialize - perform all necessary initialization } 
{ ******** } 

procedure initialize; 



var 



begin 



i: integer; 



timein := clock; 
with ctabC13 do 
"" Begin ~~ 
cname := 'MM 
cfirst := 1 
end; 
witTT ctabC23 do 
begin 

cname := 'DD 
cfirst := 4 
end; 
with c*abC33 do 
Begin 

cname := 'YY 
cfirst := 7 
end; 
with ctabC43 do 
" "Begin ~~ 
cname := 'TIME 
cfirst := 9 
end; 
wjtFctabC53 do 
begin 

cname := 'DATE 
cfirst :- 1 
end; 
with— c tab C63 do 

"Begin cname := 'T 
with ctabC73 do 



ctyp := tch; clen := 2; 



ctyp 



ctyp 



tch; clen := 2; 



clen := 2; 



ctyp := tch; clen 



ctyp := tch; clen 



8; 



8; 



begin cname := 
with ctabC83 do 

begin cname := 
with ctabC93 do 



'FALSE 



•MAXINT 



•MININT 



ctyp := tbl; 
ctyp := tbl; 



ctyp 



tre; 



cb := true end; 
cb := false end; 



cr : s maxint end; 



ctyp : s tre; 



begin cname 
ctop :- ndef const { number of predefined constants 
cvalid := ndefconst; 
timedate { put mm/dd/yyhh:mm:ss into cstr[1..16] }; 
keywords are in order of decreasing frequency of access 



= - maxint end; 

}; — 



i- lexand end; 
: s lexbeg end; 
:= lexcas end; 
:= lexcon end; 
:= lexdiv end; 
:- lexend end; 
:= lexfwd end; 
:= lexfwd end; 
:= lexfwd end; 
:= lexfun end; 
:- lexmax end; 
= lexmcon end; 
:= lexmin end; 
:= lexmod end; 
:= lexnot end; 
:= lexor end; 



with keywdC163 do begin kname := 'AND '; klex 

witF keywdC203 "So begin kname := 'BEGIN '; klex 

wTtF keywdC143 do begin kname := 'CASE '; klex 

with keywdC103 do Begin kname := 'CONST '; klex 

witF keywdC113 do Begin kname :- 'DIV '; klex 

with keywdC213 do begin kname := 'END '; klex 

witF keywdC 83 do" begin kname :- 'EXTERN '; klex 

witF keywdC 23 do" begin kname := 'FORTRAN '; klex 

witF keywdC153 do begin kname := 'FORWARD '; klex 

witF keywdC 93 do" begin kname := 'FUNCTION *; klex 

witF keywdC 43 do" Begin kname := 'MAX '; klex 

witF keywdC 33 do" begin kname := 'MC0NST '; klex : 

witF keywdC 53 do" begin kname := 'MIN ■; klex 

with keywdC 63 Ho begin kname := 'MOD '; klex 

with keywdC173 do begin kname := 'NOT '; klex 

with keywdC123 do begin kname := 'OR '; klex 

witF keywdC193 3o 

begin kname := 'PROCEDURE '; klex : = lexproc end; 

with keywdC133 do begin kname := 'RECORD '; klex := lexrec end; 

with keywdC 13 do begin kname := 'RUN '; klex := lexfwd end; 

with keywdC 73 do begin kname := 'TYPE '; klex := lextpe end; 

with keywdC183 do begin kname := 'VAR '; klex := lexvar end; 

mtop := 0; dstop := 0; defsCsysincD.dname := 'SINCLUDE '; 
defsCsysdefine3.dname := 'SDEFINE •; 
defsCsysindex3.dname := 'SINDEX '; 
defsCsysoption3.dname := '$0PTI0NS '; 

defsCsyscodeif3.dname := 'SC0DEIF '; dtop := nsysmac; 
atop := maxdefstr { actuals in rhs of dstr }; 

with functC 13 do begin fnnme := 'ABS '; fntyp := fabs end; 

with functC 23 do begin fnnme := 'ARCTAN '; fntyp := fatn end; 

with functC 33 do begin fnnme := *CHR '; fntyp := fchr end; 

with functC 43 do begin fnnme := 'COS *; fntyp := fcos end; 

with functC 53 do begin fnnme := 'EXP: '; fntyp := fexp end; 

with functC 63 do begin fnnme := 'LENGTH '; fntyp := flen end; 

with functC 73 do begin fnnme := 'LN '; fntyp := fin end; 

with functC 83 do begin fnnme := 'ODD '; fntyp := fodd end; 

with functC 93 do begin fnnme := '0RD '; fntyp := ford end; 

with functC103 do begin fnnme := 'ROUND '; fntyp := frou end; 



1871 
1872 
1873 
1874 
1875 
1876 
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1881 
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1884 
1885 
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1906 
1907 
1908 
1909 
1910 
1911 
1912 
1913 
1914 
1915 
1916 
1917 
1918 
1919 
1920 
1921 
1922 
1923 
1924 
1925 
1926 
1927 
1928 
1929 
1930 
1931 
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1950 
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1969 
1970 
1971 
1972 
1973 
1974 
1975 
1976 
1977 
1978 
1979 
1980 



fsin end; 
f sqr end; 
fstr end; 
ftru end; 



with functC113 do begin fnnme := 'SIN '; fntyp 

with functC123 Ho begin fnnme := 'SQR '; fntyp 

with functC133 do begin fnnme := 'STRING0F '; fntyp 

witF functC143 clo begin fnnme :- 'TRUNC '; fntyp 

line := { last line number for listing }; 

pline := 1 { next, not last, pascal line number }; 

rewrite(psource); rcopt :* defrc; prcopt := defprc; 

listopt := deflist; 

expropt := defexpr { parse const expressions }; 

outpos := { last output position used }; 

last lex :- lexeof { last token type output }; nerrors :« 0; 

index := 0; 

confl := Clexalpha, lexreal, lexint, lexand, lexor, lexnot, lexmin, 

lexmax, lexdiv, lexmod, lexbeg, lexcas, lexend, lexrec, lexfun, 

lexproc, lexcon, lextpe, lexvar3; 
linectr := pagesize { force newpage on listing }; 
ft op := - 1 { no open files }; open(inname); 
fstackC03.fname := inlname 
end { initialize }; 

{ ******** } 

{ need - need 1 lines: start new page if necessary } 
| ******** } 

procedure need { l:pgrng }; 



then begin linectr := I; newpg end 



begin 

if (linectr + I) > pagesize 

eTse linectr := linectr + I 
end"T~need } ; 

{ ******** j 

{ newpg - skip to a new page and print the heading } 
{********} 

procedure newpg; 

begin 
wrTteln (newpage, titlel, titlela, dte: 9, titlelb, tme: 
writeln(double, title2); writeln(space, title3); 
write(space, title4); writeln(title5, title6) 

end { newpg }; 
{ newpg } 

r ******** | 

{ open - open an included file } 
j ******** j 

procedure open { name:alfa } ; 



f: flrng; 

begin 
over(ftop, maxfiles); fstackCftop + 13.fname 
while fstackCf3.fname <> name do f : s f + 1; 
if f <= ftop then error(eropen) 
eTse 
" "Begin 

ftop := ftop + 1; 
with fstackCftop3 do 
begin 

{ ffile'must be opened with name fname 
reset(ffile); fline :- 0; last :* 0j 
inlineCnext3 :- newline; mtop 
end 
end 
end 1 open } ; 



9); 



0; 



0; 



next 
getch 



1; 



******** j 

over - abort on overflow } 
******** } 

procedure over { i: integer; maxval: integer }; 



begin if 
endT 



_ >= maxval 
over }; 



then begin error(erover); goto 1 end 



******** j 

parse the input program 



parse ■ 
******** j 

procedure parse { toprcrng; tok:lex }; 

begin 
getkey; 
while not (lextyp jn. Clexeof, lexend, lexfwd3) do 

if lextyp jm Clexrec, lexfun, lexproc, lexcon, lexmcon, lexbeg, 

lexcas3 
then 

case lextyp of_ 
Tex beg: 
begin 
puttok; 

if tok Jjn Clexproc, lexfun3 
then begin tok := lexbeg; getkey end 
else parse(ctop, lexbeg) 
enH; 
lexcas: 
begin 
puttok; 

if tok = lexrec then getkey else parse(ctop, lexcas) 
end; 
lexcon: 
begin puttok; j_f expropt then parsecon else getkey 
end; 
lexfun: begin puttok; scanheader; parse(ctop, lexfun) end; 
lexmcon: parsemcon; 
lexproc: 

begin puttok; scanheader; parse(ctop, lexproc) end; 
lexrec: begin puttok; parse(ctop / lextyp) end 
end { case~~T 
else begin puttok; getkey end; 
puttok; 



PASCAL NEWS #17 



MARCH, 1980 



PAGE 39 



1981 
1982 
1983 
1984 
1985 
1986 
1987 
1988 
1989 
1990 
1991 
1992 
1993 
1994 
1995 
1996 
1997 
1998 
1999 
2000 
2001 
2002 
2003 
2004 
2005 
2006 
2007 
2008 
2009 
2010 
2011 
2012 
2013 
2014 
2015 
2016 
2017 
2018 
2019 
2020 
2021 
2022 
2023 
2024 
2025 
2026 
2027 
2028 
2029 
2030 
2031 
2032 
2033 
2034 
2035 
2036 
2037 
2038 
2039 
2040 
2041 
2042 
2043 
2044 
2045 
2046 
2047 
2048 
2049 
2050 
2051 
2052 
2053 
2054 
2055 
2056 
2057 
2058 
2059 
2060 
2061 
2062 
2063 
2064 
2065 
2066 
2067 
2068 
2069 
J370 
c.071 
2072 
2073 
2074 
2075 
2076 
2077 
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2089 
2090 



if (lextyp = lexeof) and (tok <> Lexeof) 
tFen begin error(erparseof); goto 1 end 
else 

TT (Lextyp = Lexend) and not (tok in Clexbeg, lexcas, Lexrec3) 

TFen error(erparsend) 

else 

TT (lextyp = Lexfwd) and not (tok vn Clexproc, Lexfun3) 
tFen error(erparsfwd); 
if lextyp <> lexeof then getkey; ctop := top; cvalid := top 
encH parse } ; 

{ ******** \ 

{ parsecon - parse a constant declaration with expression } 
i ******** } 

procedure parsecon; 

var 

savtyp: lex; 
savstr: strng; 
savlen: Inrng; 
svalid: boolean; 
consnam: alfa; 

begin 
getkey; 
whi le lextyp = lexalpha do 



puttok; over(ctop, maxcons); ctop := ctop +1; 
packdexstr, 1, consnam); getkey; 
if lextyp <> lexeq 
tFen 
Eegin 

error(erparscon); ctabCctop3.ctyp := terr; flush; 
getkey 
end 
else 
Begin 

puttok; getkey; while ch = blank do getch; 
if (ch = semi) and (lextyp jin Clexint, lexreal, lexother3) 
tFen 
Begin 

savstr := lexstr; savlen := lexlen; 
savtyp : = lextyp; svalid := true 
end 
else svalid := false; 
expression; 
if (lextyp <> lexsemi) and (not typeis(Cterr3)) then 

begin experror(erpconsyn); ctabCctop3.ctyp := terr end; 
if ctabCctop3.ctyp <> terr 
tFen 
begin 
if svalid 
TFen 
begin 

lexstr := savstr; lextyp := savtyp; 
lexlen := savlen 
end 
else convrt; 

puttok; lextyp := lexsemi; lexstrCID := semi; 
lexlen := 1; puttok; ctabCctopD.cname := consnam; 
cvalid := ctop 
end 
else 
begin 

lexstrCID := zero; LexstrC23 := semi; 
lextyp := lexst; lexlen := 2; puttok 
end 
end; 
if ctabCctop3.ctyp jn. Cterr, tot3 then ctop := ctop - 1; 
getkey 
end 
end 1 parsecon } ; 

{ ******** j 

{ parsemcon - parse an internal constant declaration with expression } 
{ ******** j 

procedure parsemcon; 

var 

consnam: alfa; 

begin 
getkey; 

whi le lextyp = lexalpha do 
begin 

over(ctop, maxcons); ctop := ctop + 1; 
packdexstr, 1, consnam); getkey; 
if lextyp <> lexeq 
then 
begin 

error(erparsmcon); ctabCctopD.ctyp := terr; flush; 
getkey 
end 
else 
begin 

getkey; while ch = blank do getch; expression; 
if (lextyp <> lexsemi) and TiTot typeis(CterrD)) then 

begin experror(ermconsyn); ctabCctopD.ctyp := terr end; 
if ctabCctop3.ctyp <> terr then 
begin ctabCctopD.cname := consnam; cvalid := ctop end 
end; 
if ctabCctop3.ctyp jjn [terr, totD then ctop := ctop - 1; 
getkey 
end 
end { parsemcon }; 

{ ******** \ 

{ pushback - push character back onto input } 
{ ******** \ 
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2200 



procedure pushback; 
begin 



mtop > then with mstackCmtopD do mnext : s mnext - 1 

else next := next -~1 
end { pushback }; 

{ ******** i 

{ puttok - put out a token for pascal using cols 1-prc } 
s ******** } 

procedure puttok; 



i: Inrng; 

begin 

If (lastlex in conf I) and (lextyp Jjn conf I) then 
begin 
write (psource, blank) { space needed between tokens }; 
outpos := outpos + 1 
end; 
if lextyp = lexeof then begin writeln(psource); outpos :* < 
eTse 
"Begin 

if (outpos + lexlen) > prcopt 
then 
begin 
pline := pline +1; writeln(psource); outpos :» 0; 
if lexlen > prcopt 

then begin error(erputtok); lexlen :- prcopt end 
encl; 
for i := 1 tjo lexlen do write(psource, lexstrCiD); 
outpos := outpos + lexlen; lastlex := lextyp 
end 
end { puttok }; 

{ ******** j 

{ relate - parse subexpression with rel. ops } 
{ ******** j 
procedure relate; 



op: lex; 

i: integer; 

r: real; 
d, 

c2: csrng; 

begin 
arTth; 
while (lextyp jn Clexlt .. 

over(ctop, maxcons); 
getkey; arith; 
if typesmatch 
then 

with ctabCctop - 13 do 
case ctyp of 
tin: 
begin 

i := ci; ctyp 
case op of_ 
lexlt: cb := 
lexle: cb := ■ 
lexeq: cb := 
lexge: cb := 
lexgt: cb := ' 
lexne: cb := 



end { case } 



lexne]) and (not typeis(Cterr3)) do 
ctop := ctop +1; op := lextyp; 



:= tbl; 

< ctabCctopD.ci; 
<= ctabCctopD.ci; 
= ctabCctopD.ci; 
>= ctabCctopD.ci; 
> ctabCctop3.ci; 
<> ctabCctopD.ci 



tre: 
bee 



in 



tbl; 



r := cr; ctyp 
case op of 

lexlt: cb 

lexle: cb 

lexeq 

lexge 

lexgt 

lexne: cb := r <> ctabCctop3.cr 



cb 
cb 
cb 



= r < ctabCctop3.cr; 
= r <= ctabCctopD.cr; 
= r - ctabCctop3.cr; 
= r >= ctabCctopD.cr; 
r > ctabCctopD.cr; 



case } 



cb < ctabCctopD.cb; 
cb <= ctabCctopD.cb; 
cb = ctabCctopD.cb; 
cb >- ctabCctop3.cb; 
cb > ctabCctop3.cb; 
cb <> ctabCctop3.cb 



ctyp 



terr end; 



end { 
end; 
tbl: 

case op of 
Tex It: cb 
lexle: cb 
lexeq: cb 
lexge: cb 
lexgt: cb 
lexne: cb 
end; 
tot: begin experror(errelatyp); 
tch: 
begin 

d := cfirst; c2 := ctabCctop3.cfirst; i := 1; 
while (i < clen) and (cstrCc13 = cstrCc23) do 

i := i + 1; 
estop := estop - clen - ctabCctop3.clen; 
ctyp := tbl; 
case op of_ 

lexlt: cb := cstrCc13 < cstrCc23; 
lexle: cb := cstrCc13 <= cstrCc23; 
lexeq: cb := cstrCc13 = cstrCc23; 
= cstrCc13 >= cstrCc23; 
= cstrCc13 > cstrCc23; 
= cstrCc13 <> cstrCc23 



Lexge: cb 

Lexgt: cb 

Lexne: cb 

end { case 

end 

end 1 case } 



} 
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if ctabCctop]. ctyp <> terr 
TFen begin experror(errelconf ); 
ctop : = ctop - 1 
end 
end 1 relate }; 



ctabCctop]. ctyp := terr end; 



{ ******** \ 

{ scanheader - scan procedure or function heading } 
{ ******** i 

procedure scanheader; 



ctr: integer; 

begin 
getkey { get name }; puttok { get name }; 
get key { get paren if parameters }; 
if Lextyp <> LexLparen then puttok 
eTse 
Begin 

ctr := 1; puttok; 
repeat 
getkey; j_f Lextyp = LexLparen then ctr := ctr + 1; 
if Lextyp = Lexrparen then ctr := ctr - 1; puttok 
untTL ctr = 
end 
end 1 iscanheader } ; 

{ ******** \ 

{ term - process multiplication ops in expression } 
{ ******** \ 

procedure term; 



op: Lex; 

begin 
factor; 

if (Lextyp _i_n CLexand .. LexmodD) and (not typeis(Cterr])) 
Wen 

TT (typeis(CtbL]) and (Lextyp = Lexand)) or (typeis(Ctrel) and ( 
Lextyp jn_ CLexmuLt •• Lexmax])) or (typeis(CtinD) and (Lextyp 
in CLexmuLt .. LexmodD)) 
then 

wKiLe Lextyp in CLexand .. LexmodD do 
" "Begin "~ 

ctop := ctop + 1; op := Lextyp; getkey; factor; 
with ctabCctop - 13 do 

TT (op = Lexand) and" (ctyp = tbL) 
TFTen cb := cb and ctabCctop]. cb 
else 

TT (op JE CLexdiv .. Lexmod3) and (ctyp = tin) 
tTTen 

case op of 

Lexdiv: ci := ci div ctabCctop]. ci; 
Lexmod: ci := ci mod ctabCctop}. ci 
end { case } 
else 
TT (op jn_ CLexmuLt .. Lexmax]) and typeis(Ctin, tre]) 
tTTen 
"Begin 

if (ctyp = tin) and typeis(CtinD) and (op <> 

Lexdvd) 
then 
case op o_f 

LexmuLt: ci := ci * ctabCctop]. ci; 
Lexmin: 
if ctabCctop]. ci < ci 
then ci := ctabCctop]. ci; 
Lexmax: 
if ctabCctop]. ci > ci 
then ci := ctabCctop]. ci 
end "{ case } 
eLse 
begin 
foFcereaL; 
case op of 

LexmuLt: cr := cr * ctabCctop]. cr; 
Lexdvd: cr := cr / ctabCctop]. cr; 
Lexmin: 

if ctabCctop], cr < cr 
then cr := ctabCctop]. cr; 
Lexmax: 

if ctabCctop]. cr > cr 
then cr := ctabCctop]. cr 
end T case } 
end 
end 
eLse 

if ctabCctop]. ctyp <> terr 
then experror(ertermtyp); 
ctop := ctop - 1 
end 
eLse error(ertermtyp) 
end 1 term }; 

{ ******** \ 

{ terminate - print statistics and close files } 

i ******** x 

procedure terminate; 
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ratio: reaL { lines/sec ratio }; 

begin 

if outpos > then writeLn(psource); 

if nerrors > then 

"" Ijegin 

need(2); 

writeLn(doubLe, ' — > there were ', nerrors: 1, 
* errors detected by map'); 
end; 
tottme := cLock - timein; 
if tottme = then ratio := 0.0 
eTse ratio := 1000" * Line / tottme; 
need (2); 

writeLn(doubLe, ' — > end run: *, Line: 5, ' input lines,', pLine: 6 
, ' output Lines,', tottme: 7, ' MS (', ratio: 8: 4, 
' Lines/sec)'); 
end { terminate }; 

{ ******** \ 

{ timedate - get time and date and store in cstr } 
j ******** \ 

procedure timedate; 

begin { get time and date from system and make } 
{ cstr [1.. 16] mm/dd/yyhh:mm:ss 
{ 

{ global variables tme and dte should be 
{ set to time and date for the listing 
{ temporary time and date 

unpackOMM/DDWH^MM^S', cstr, 1); tme :- '*TIME* '; 
dte := '*T0DAY* ' 
end { timedate }; 

r ******** j 

{ typeis - return true if type of top of stack is in set } 
{ ******** j 

function typeis { c:cset) zboolean }; 
begin typeis := ctabCctop]. ctyp vn c end { typeis }; 

r ******** \ 

{ typesmatch - return true if types of top operands compatible } 
^ ******** j 
function typesmatch { ;boolean }; 

begin 
typesmatch := faLse; 
with ctabCctop - 1] do 

if ctyp = ctabCctop]. ctyp then 

if ctyp <> tch then typesmatch := true 
eLse if cLen = ctabCctop]. cLen then typesmatch := true 
end { typesmatch }; 

j ******** \ 

{ variable - recognize variable in expression } 
^ ******** j 

procedure variabLe; 



name: aLfa; 
found: boo Lean; 
fun: fns; 

begin 

if not (Lextyp vn CLexaLpha, Lexint, LexreaL, Lexst]) 

then begin experror(ervaLexp); ctabCctop]. ctyp :* terr end 

eLse 

case Lextyp of 

Texint: begTn convrti; getkey end; 
LexreaL: begin convrtr; getkey end; 
Lexst: begin convrts; getkey end; 
LexaLpha: 
begin 
packUexstr, 1, name); getkey; found := faLse; 
if Lextyp <> LexLparen 
then 
begin 

f indcon(name, found); 
if not found then 
with ctabCctop] do 

begin ctyp := tot; co := name end 
end 
eLse 
begin 

f Lookup (name, fun, found) { function call }; 
if not found then experror(ervarfnct) 
eTse 
begin 
getkey; expression; 

if Lextyp <> Lexrparen then experror(ervarrpar) 
eLse begin getkey; evaLfns(fun) end 
en? 
end 
end 
end 1 case } 
end 1 var iable } ; 
begin { map } 
initialize; parse(ctop, Lexeof); 
1 : terminate end. 



***************** 
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program Xref(input, output, tty) { N. Wirth 10.2.76 

Cross Reference generator for Pascal programs 
quadratic quotient hash method 
revised by R.J.Cichelli 16-Feb-79 
include perfect hash function, ring data structures, 
and clean up code, 
revised by J.P.McGrath 22-May-79 
predefined identifier processing 
modified quicksort algorithm 
command line processing by M.Q.Thompson 
revised by R.J.Cichelli 26-Nov-79 
string table processing and work-files 
Copyright 1979 Pascal Users Group 

permission to copy - except for profit - granted 

* Purpose: 

This program cross references Pascal programs. 

It supports upper and lower case, long identifiers and 

long programs. 

* Authors: 

N. Wirth, R.J.Cichelli, M.Q.Thompson, J.P.McGrath. 

* Method: 

Quadratic quotient hash method with tagged, quick-sorted string 
table and perfect hash function reserved word and predefined 
identifier filters. Overflow processing by multi-file merge-sort. 

* Description of parameters: 

DEC PDP 11 RSX protocol. 

PXR <output file>»< input file> [<options>] 

<options> ::= 

C- captalize identifiers, 

D+ display program, 

P- cross reference predefined identifiers, 

TV- terminal output (80 columns and ids. only) , 

W=132 width of output. 

* Input: 

Pascal Program source. 

* Output: 

Listing and references. 

* Limitations: 

* Computer system: 

Program was run under Seved Torstendahl ' s DEC PDP 11 RSX Pascal. 
This compiler (version 4.5) doesn't support program parameters 
in full generality. In this program implememtation specific 
code handles control card cracking and file variable and system 
file name associations. 

* Installation under RSX: 

DPI : XREF/-FP/MU, TT : /SH=DP1 : XREF . ODL/MP 

TASK=...PXR 

LIBR=SYSRES:RO 

EXTSCT=$HEAP1 : 40000 

EXTSCT»$$FSR1:5140 

UNITS=6 



// 



Rl: 

01: 

02: 

021: 

022: 

03: 



;ODL (overlay description) 

.ROOT Rl-*(01,02) 

.FCTR DPI: XREF/LB: XREF :PAGEHE-DP0: [1,1]PASLIB/LB 

.FCTR DPI :XREF/LB: QUICKS 

. FCTR DPI : XREF/LB : INITPE-03-* (021 , 022) 

.FCTR DPI: XREF/LB :INITCH 

. FCTR DPI : XREF/LB : INITPR 

. FCTR DP0 : [1 , 1] PASLIB/LB : GCML 



{$R- 
{$W- 



no runtime testing 
no warning messages 



'<•; 

'>'; 



quote = "", 
LCurleyBra = 
rCurleyBra = 
HashTblSize = 997 
Maxltems = 4000 { 
StgTblSize = 6000 
StgTblLimit = 5900 
NumOfReserved = 40 
NumOfPredefnd = 48 
keylength = 10 
DigitsPerNumber = 6 
LinesPerPage = 57 
DefaultTerminalWidth 
DefaultLpWidth = 132 
MaxLineNo - maxint 



{ size of hash table - prime 
arbitrary limit on incore references 



string table size 
{ limit is size - 100 
{ size of reserved word table 
{ size of predefined id table 
{ keylength 

{ no. of digits per number 
{ lines/page 
80 { terminal width 

line printer width 
maximum line number 



{ 



type 



text = file of char; 
index = .. HashTblSize; 
StgTbllndx = 1 .. StgTblSize; 

alfa = packed array C1 .. 
ItemPtr = "item; 
word = record 



keylength] o_f char; 



keyindx, 
keylen: StgTbllndx; 
lastptr: ItemPtr 



end; 
item = packed record 



LineNumber: 
next: 



.. MaxLineNo; 
ItemPtr 
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LineBuffer = packed array C1 .. 80] o_f char; 
ChrType = (ucLetter, IcLetter, digit, other); 
FilStates = (inout, inwrkl, wrklout, wrk1wrk2, wrk2out / 
wrk2wrk1); 



charindx, 
idlen, 

HshTbllndx: integer; 

empty: alfa; 

identifier: alfa; 

CurrentLineNumber: integer 

LinesOnPage: integer 

LineNosPerLine: integer 



{ 



'9' } 3 of integer; 



current line number }; 
number of lines on current page }; 
no. of line-numbers per line }; 
HashTable: array [index] o_f word { hash table }; 
StgTable: packed array CStgTbllndx] of char 

T for storing Identifiers } ; 
FreeStgPtr: integer; 
FreeltemPtr: ItemPtr; 
ItemCnt: integer; 
ChrCatagory: array Cchar] of ChrType; 
ChrSortOrd: array Cchar] of integer; 
ReservRepresentedBy, 
PredefRepresentedBy: array Cchar { 'A' 
LastLeadingChar, 
ch, 
rawch, 
fstchar, 
Istchar: char; 
reserved: array C1 

predefined: array C1 

LineLength: integer; 
cmlline: LineBuffer; 
cmllen: integer; 
today, 

now: packed array [1 '.. 10] of_ char; 
OutputSection: (listing, idents); 
PageNumber: integer; 
DisplaylsActive, 
DoPredef ined, 
terminal, 
AUCapitals: Boolean; 

state: FilStates; 
NextState: array [FilStates, Boolean] o_f FilStates; 
wrk2active: Boolean; 
wrkl, 
wrk2: text; 

procedure Pageheader; 



NumOfReserved! of alfa; 
NumOfPredefnd] of alfa; 



IsNarrow: 



integer; 
.. 1; 



1; end 



begin 

IsNarrow := 0; 
if not terminal 
then 
begin 

PageNumber := PageNumber +1; page(output); 
writeC CrossRef - '); 
case OutputSection £f 

listing: writeCProgram Listing 
idents: writeCldentifier Cross-Reference 
end; 

writeC ', today, ' ', now: 8); 
if LineLength <= DefaultTerminalWidth 
then begin writeln; writeC* '); IsNarrow 
else writeC '); 
for i := 1 to cmllen d£ write(cmlline[i]); 
wrTteC ': T2"5 * IsNarrow + 40 - cmllen)); 
writelnC Page ', PageNumber: 3); writeln; 
end; 
LinesOnPage := IsNarrow; 
end { pageheader }; 

function UpperCase(ch: char): char; 

begin { This should work for both ASCII and EBCDIC. } 

if ChrCatagoryCch] = IcLetter 

then Uppercase := chr(ord(ch) - ordCa') + ord('A')) 

else Uppercase := ch; 
end { uppercase } ; 

function EqlStg(indx1, lenl, indx2, len2: integer): Boolean; 



disp, 
StopAt: 




disp] = StgTableC 



len2 then EqlStg := false 



isp := 0; StopAt := lenl - 1; 
while (disp < StopAt) and (StgTableCindxl 
indx2 + disp]) do 
disp := disp + 1; 
EqlStg := StgTable[indx1 + disp] - StgTableCindx2 + disp] 
end 
end { eqlstg } ; 

function LssStg(indx1, lenl, indx2, len2: integer): Boolean; 



StopAt, 

disp, 

point: 

begin 
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if Len1 < Len2 then StopAt := lenl - 1 else StopAt := len2 - 1; 
dTsp := 0; 

while (StgTableCindxl + disp] = StgTableCindx2 + disp]) and (disp < 
StopAt) do 
disp := d"Tsp + 1; 
point := disp; 

while (UpperCase(StgTableCindx1 + disp]) = UpperCase(StgTableCindx2 
+ disp])) and (disp < StopAt) do 
disp := disp + 1; 
if UpperCase(StgTableCindx1 ♦ disp]) = UpperCase(StgTableCindx2 + 

disp]) 
then 

~~ 7f lenl = len2 
then 

LssStg := ChrSortOrdCStgTableCindxl + point]] < ChrSortOrdC 
StgTableCindx2 + point]] 
else LssStg :* lenl < len2 
else 

LssStg := ChrSortOrdCStgTableCindxl + disp]] < ChrSortOrdCStgTable 
Cindx2 ♦ disp]]; 
end { lssstg }; 

{$Y+ new segment } 

procedure PrintTables (var infil, out: text); 



tryindx, 
trylen: integer { quick sort temporaries 
SwapWord: word { quicksort temporary }; 
midpoint: integer; 
Tbllndx, 
MoveToIndx: index; 

i: integer; 
NumberCounter: integer; 
CmpRefPtr, 
CmpRefLen: integer; 

procedure Quicksort (LowerBound, UpperBound: integer); 



TmpLowerBnd, 
TmpUpperBnd: 



integer; 



TmpUpperBnd := UpperBound; 
TmpUpperBnd) div 2; 



begin 
repeat 
TmpLowerBnd := LowerBound; 
midpoint := (TmpLowerBnd 
tryindx := HashTableCmidpoint].keyindx; 
trylen := HashTableCmidpoint].keylen; 
repeat 
while Lss$tg(HashTableCTmpLowerBnd].keyindx, HashTableC 
TmpLowerBnd], key len, tryindx, trylen) do 
TmpLowerBnd := TmpLowerBnd +1; 
while Lss$tg(tryindx, trylen, HashTableCTmpUpperBnd]. keyindx, 
HashTableCTmpUpperBnd].keylen) do 
TmpUpperBnd :- TmpUpperBnd - 1; 
if TmpLowerBnd <= TmpUpperBnd 
then 
begin 

SwapWord := HashTableCTmpLowerBnd]; 
HashTableCTmpLowerBnd] := HashTableCTmpUpperBnd]; 
HashTableCTmpUpperBnd] :- SwapWord; 
TmpLowerBnd := TmpLowerBnd + 1; 
TmpUpperBnd := TmpUpperBnd - 1 
end 
until TmpLowerBnd > TmpUpperBnd; 

if TmpUpperBnd - LowerBound < UpperBound - TmpLowerBnd 
tTTen 
"Segin 

if LowerBound < TmpUpperBnd 
tFen Quicksort (LowerBound, TmpUpperBnd); 
LowerBound := TmpLowerBnd; 
end 
else 
begin 

if TmpLowerBnd < UpperBound 
then Quicksort (TmpLowerBnd, UpperBound); 
UpperBound :- TmpUpperBnd; 
end; 
until UpperBound <= LowerBound; 
encT t quicksort } ; 

procedure EndLine(achar: char); 

begin 

if OutputSection = idents 
then 
begin 

writeln(out); LinesOnPage := LinesOnPage + 1; 
if LinesOnPage > LinesPerPage 
then begin Pageheader; LinesOnPage := 1 end; 
end 
else writeln(out, achar); 
endTendline }; 

procedure PrintNumbers(aword: word); 



LoopPtr, 
TailPtr: ItemPtr; 



ailPtr := aword.lastptr; 
Tai LPtr := LoopPtr; 
repeat 

if NumberCounter : 
begin 

NumberCounter 
write(out, ' 



LoopPtr := Tai IPtr". next; 



LineNosPerLine then 



0; EndLineC,'); 
keylength + ord(0utputSection = idents)); 
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end; 
NumberCounter := NumberCounter +1; 
write(out, LoopPtr ".LineNumber: DigitsPerNumber); 
LoopPtr := LoopPtr ".next 
until LoopPtr - TailPtr; 
{ free ring } 
aword.lastptr*. next := FreeltemPtr; FreeltemPtr := LoopPtr; 
EndLineC); 
end { printnumbers }; 

procedure NextRef; 

begin 



CmpRefLen > 
then 

CmpRefLen := 0; 
if not eof(infil) then 
repeat 

StgTableCCmpRefPtr + CmpRefLen] := infil"; 
CmpRefLen := CmpRefLen + 1; get(infil) 
until (infil" = ■ ') 
end 
end { nextref } ; 

procedure 0utId(keyptr, lenkey: integer; SetUpForNos: Boolean); 

var 

chindx: integer; 

begin 

if OutputSection = idents 
then 
begin 

if (LinesOnPage + 4) > LinesPerPage 
then begin Pageheader; LinesOnPage := 1 end 
else 
TF LastLeadingChar <> UpperCase(StgTableCkeyptr]) 
then EndLineC '); 
wrTteTout, ' *); 

LastLeadingChar := UpperCase(StgTableCkeyptr]); 
end; 
for chindx := keyptr to keyptr + lenkey - 1 do 

write(out, StgTableTchindx]); 
vf SetUpForNos 
then 
begin 

if lenkey > keylength 
then 
begin 

wr7te(out, ' ': ((DigitsPerNumber - 1) - ((lenkey - ( 

keylength + 1)) mod DigitsPerNumber))); 
NumberCounter := ((lenkey - keylength) div DigitsPerNumber 
) + 1; 
end 
else 
begin 
write(out, ' ': (keylength - lenkey)); 
NumberCounter := 
end; 
end 
end I butid } ; 

procedure CopyRef (AllOflt: Boolean); 

var 

lastlen: integer; 

procedure CopyLines; 



RefDone: Boolean; 
savech: char; 

begin 

lastlen := CmpRefLen; RefDone := false; 
repeat 
repeat 

write(out, infil"); lastlen := lastlen + 1; get(infil) 
until (infil" = '.') or (infil" = ',') or_ eoln(infil); 
savech := infil"; 
if savech - ' .' 
TFen 
begin 

RefDone := true; 
if not AllOflt then 
begin 

savech := • '; 

NumberCounter := ((lastlen - keylength) div 
DigitsPerNumber); 
end; 
end 
else lastlen := 0; 

while not eoln(infil) do get(infil); 
vf eof(infil) 

then begin CmpRefLen := 0; RefDone := true; end 
else get(infil); 
if savech <> ' ' then 
begin 

EndLine(savech); 

if not RefDone and (OutputSection = idents) 
then write(out, ' '); 
end; 
until RefDone 
end { copy lines }; 



begin { copyref } 

0utId(CmpRefPtr, CmpRefLen, false); 
end { copyref }; 



CopyLines; 
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441 
442 
443 
444 
445 
446 
447 
448 
449 
450 
451 
452 
453 
454 
455 
456 
457 
458 
459 
460 
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463 
464 
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466 
467 
468 
469 
470 
471 
472 
473 
474 
475 
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477 
478 
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481 
482 
483 
484 
485 
486 
487 
488 
489 
490 
491 
492 
493 
494 
495 
496 
497 
498 
499 
500 
501 
502 
503 
504 
505 
506 
507 
508 
509 
510 
511 
512 
513 
514 
515 
516 
517 
518 
519 
520 
521 
522 
523 
524 
525 
526 
527 
528 
529 
530 
531 
532 
533 
534 
535 
536 
537 
538 
539 
540 
541 
542 
543 
544 
545 
546 
547 
548 
549 
550 



procedure syncronizeCaword: word); 



done: Boolean; 

begin 

done := false; 
with aword do 
repeat 

if CmpRefLen = 

tFen begin done := true; OutId(keyindx, keylen, true); end 

else 

vF LssStg(CmpRefPtr, CmpRefLen, keyindx, keylen) 

tFen begin CopyRef (true); NextRef end 

else 

tT EqlStg(CmpRefPtr, CmpRefLen, keyindx, keylen) 

THen begin CopyRef (false); NextRef; done := true; end 

else 

begin 0utId(keyindx, keylen, true); done := true; end; 
until done; 
end { syncronize }; 

begin { pcinttables } 

LinesOnPage :* LinesPerPage; MoveToIndx := { compress table }; 
for Tbllndx :* to HashTblSize - 1 do 
Ti HashTableCTbTTndx]. keyindx <> O Then 
begin 

HashTab LeCMoveToIndx] -.- HashTableCTbllndx]; 
MoveToIndx := MoveToIndx + 1 
end; 
if MoveToIndx > then QuickSort(0, MoveToIndx - 1); 
UneNosPerLine i- (LineLength - keylength - 1) d_W Digit sPerNumber; 
CmpRefPtr := FreeStgPtr + idlen; LastLeadingChar := • '; 
if state > inwrkl 

tHen begin CmpRefLen := 1; NextRef { first reference }; end 
else CmpRefLen := 0; 
TF~HashTableC0]. keyindx <> then 

for Tbllndx :* to MoveToIndx - 1 do 
Begin 

syncronize(HashTableCTblIndx]); 
PrintNumbers (HashTableCTbllndx]); 
end; 
whi le CmpRefLen <> do begin CopyRef (true); NextRef; end; 
end" ! printtables }; 

procedure DumpTables; 



chptr: integer; 



idents)]; 



state := NextStateCstate, (OutputSection 
case state of 
Tnout: PrTntTables( input { dummy }, output); 
inwrkl: 
begin 
{} rewrite(wrk1, 'XRF1JNK.TMP;1 ',, 'DPO:'); 
PrintTablesCinput { dummy }, wrkD; 
end; 
wrklout: 
begin 
{} reset(wrk1, 'XRF1JNK.TMP;1 ',, 'DPO:'); 
PrintTables(wrk1, output); 
end; 
wrk1wrk2: 
begin 
{} reset(wrk1, •XRFUNK.TMP^',, 'DPO:'); 
{} rewrite(wrk2, , XRF2JNK.TMP;1'„ 'DPO:'); 

wrk2active := true; PrintTables(wrk1, wrk2); 
end; 
wrkZout: 
begin 
{} reset(wrk2, 'XRF2JNK.TMP;1'„ 'DPO:'); 
PrintTables(wrk2, output) 
end; 
wrkZwrkl : 
begin 
{} reset (wrk2, , XRF2JNK.TMP;1' 
{} rewrite<wrk1, , XRF1JNK.TMP;1 ',, 
PrintTables(wrk2, wrkD 
end 
end t case }; 
if OutputSection <> idents 
tFen 
Begin 

ItemCnt := 0; 

for HshTbllndx := to HashTblSize do 
HashTableCHshTbllndT]. keyindx := TJJ 
for chptr := 1 to idlen do 

StgTableCchptTT := StgTableCFreeStgPtr + chptr - 13; 
FreeStgPtr := 1; 
end; 
end 1 dump tables }; 

procedure scan; 

label 



'DPO:'); 
•DPO:'); 



exit scan on eof while processing comment 
procedure advance; 



then write(rawch); get(input); 
ch := UpperCase(input'); 



begin 

if DisplaylsActive 

rawch : s input"; 
end { advance }; 

procedure OpenLine; 

begin 
CurrentLineNumber := CurrentLineNumber + 1; 



551 
552 
553 
554 
555 
556 
557 
558 
559 
560 
561 
562 
563 
564 
565 
566 
567 
568 
569 
570 
571 
572 
573 
574 
575 
576 
577 
578 
579 
580 
581 
582 
583 
584 
585 
586 
587 
588 
589 
590 
591 
592 
593 
594 
595 
596 
597 
598 
599 
600 
601 
602 
603 
604 
605 
606 
607 
608 
609 
610 
611 
612 
613 
614 
615 
616 
617 
618 
619 
620 
621 
622 
623 
624 
625 
626 
627 
628 
629 
630 
631 
632 
633 
634 
635 
636 
637 
638 
639 
640 
641 
642 
643 
644 
645 
646 
647 
648 
649 
650 
651 
652 
653 
654 
655 
656 
657 
658 
659 
660 



if DisplaylsActive 
then 
begin 

if LinesOnPage >= LinesPerPage then Pageheader; 
writeC ', CurrentLineNumber: DigitsPerNumber, ' '); 
LinesOnPage := LinesOnPage +1; 
end; 
end "I bpenline } ; 



procedure CloseLine; 

begin 

get(input); rawch := input"; ch 
if DisplaylsActive then writeln; 

end { closeline }; 

procedure enter; 



UpperCase(input"); 



hashval, 

FstHashVal, 

displacement: 

NewItemPtr, 

TailPtr: 

found: 

i: 



integer; 

ItemPtr; 
Boolean; 
integer; 



procedure MakeNew(var AnltemPtr: ItemPtr); 

begin 

Tf (ItemCnt > Maxltems) or (FreeStgPtr > StgTblLimit) 

then DumpTables; 

if FreeltemPtr = nil then new (AnltemPtr) 

eTse 

AnltemPtr := FreeltemPtr; FreeltemPtr := AnltemPtr* -next 
end; 
ItemCnt := ItemCnt + 1 
end { makenew } ; 

begin { enter } 
MakeNew(NewItemPtr); hashval := 1; 
for i := FreeStgPtr to FreeStgPtr + idlen - 1 do 
hashval := (hashvaT* 17 + abs(ord(StgTableClT) - ord('A'))) mod 
HashTblSize; 
FstHashVal := hashval; found := false; displacement :■ 1; 
NewItemPtr". Li neNumber := CurrentLineNumber; 
repeat 

if HashTableChashval]. keyindx = 
then 
begin { new entry } 

found :- true; HashTableChashval]. keyindx :- FreeStgPtr; 
HashTableChashval]. keylen := idlen; 
FreeStgPtr := FreeStgPtr + idlen; 
HashTableChashvalH.lastptr := NewItemPtr; 
NewItemPtr*. next := NewItemPtr; 
end 
else 

if EqlStg(FreeStgPtr, idlen, HashTableChashvaU. keyindx, 

HashTableChashva ID. keylen) 
then 
Begin { found } 

found := true; TailPtr := HashTableChashvalD.lastptr; 
NewItemPtr*. next := TailPtr*. next; 
TailPtr*. next := NewItemPtr; 
HashTableChashvalD.lastptr := NewItemPtr; 
end 
else 
Begin { collision } 

hashval := (hashval + displacement) mod HashTblSize; 
displacement := displacement + 2; 
if displacement > 2 * HashTblSize then 
begin 
DumpTables; hashval := FstHashVal; 
displacement := 1; 
{ start over } 
end 
end 
until found 
end" l enter } ; 



begin 



scan j 

"eof ( i nput ) 

then begin writeln(tty, ' Empty input file.'); goto 1; end; 
rawch := input*; ch := UpperCase(input'); 
while not eof (input) do 
begin 
OpenLine; 

while not eoln(input) do 
begin 

ri_ ch = ' • then advance 
else 

if ChrCatagoryCchD jn_ CucLetter, IcLetterD 
tFen 
begin 

charindx := 0; idlen := 0; identifier := empty; 

fstchar := ch; 

repeat 

if charindx < keylength then 



charindx := charindx + 1; 
identifierCcharindx3 := ch; 
end; 
jf"AU Ca P itaLs 

then StgTableCFreeStgPtr + idlen3 := ch 
else StgTableCFreeStgPtr + idlen] := rawch; 
idlen := idlen + 1; advance 
until not (ChrCatagoryCchU jn_ CucLetter, digit]); 
Istchar : s identifierCcharindx]; 
if idlen > charindx then enter 
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740 
741 
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751 
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755 
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758 
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764 
765 
766 
767 
768 
769 
770 



else 


771 


if ord('A') = 193 then { 


EBCDIC } MaxCharOrd := 255 




TT identifier <> reservedCcharindx + 


772 


else 






ReservRepresentedByCfstchar] + 


773 


rf_ ord('A') = 65 then { ASCII } MaxCharOrd :- 127 




ReservRepresentedByClstchar33 { perfect hash } 


774 


else MaxCharOrd := DefaultMaxCharOrd; 




then 


775 


for i :== MinCharOrd to MaxCharOrd do 




if DoPredefined then enter 
else 


776 
777 


begin ChrCatagoryCchr(i)3 := other; ChrSort0rdCchr(i)3 := 
end; 


0; 


if identifier <> predefinedCcharindx + 


778 


for ch := '0* to '9' do 






PredefRepresentedByCfstchar3 + 


779 


begin 

Cn"rCatagoryCch3 := digit; 






Predef Represent edBy Cist char33 


780 






then enter; 


781 


ChrSort0rdCch3 := 100 + ord(ch) - ord('O'); 




end 


782 


end; 
{ Should work for all Pascal ca 






else" 


783 


npatible character sets } 




TT ChrCatagoryCch3 = digit 


784 


{ which are contiguous and for EBCDIC as well. } 




tFen 


785 


InitChrVaK'a', 'i', 2); InitChrValC j ', 'r', 20); 




repeat advance; if ch = ',' then advance 
until (ChrCatagoryTchl <> digit) and (ch <> 'E') 


786 


InitChrVaK's', 'z', 38); 






787 


end { initletdig }; 






} and (ch <> 'B') and (ch <> 'e'l 


788 








else 


789 


procedure InitPerfect; 






TT ch = quote 


790 








then 


791 


procedure InitReserved; 






begin { string } 


792 








repeat advance 

until (ch = quote) or_ eoln(input); 


793 


var 






794 


ch: char; 






if not eoln(input) then advance 


795 








end""* 


796 


begin { RJC's perfect hash function } 

"i for Pascal's reserved words and predefined identifiers 




else 


797 


} 


if ch = ICurleyBra 


798 


{ table index = identifier length + } 




tFen 


799 


{ reservrepresentedby! identifier's first character] + } 


Begin { comment } 
advance; 


800 


{ reservrepresentedby [identifier's last character] 


} 


801 


for ch := '0' to '9' do ReservRepresentedByCch3 : s 0; 




while ch <> rCurleyBra do 


802 


ReservRepresent edBy C ' A ' 3 


= 11; 






begin 
advance; 


803 


ReservRepresentedByC 'B * 3 


= 15; 


ReservRepresentedByC CD :» 


1; 


804 


ReservRepresentedByC 'D' 3 


■ 0; 


ReservRepresentedByC 'E' 3 :* 


0; 


while eoln(input) do 


805 


ReservRepresentedByC ' F ' 3 


- 15; 


ReservRepresentedByC 'G' 3 :* 


3; 


begin 

CloseLine; 


806 


ReservRepresentedByC 'H' 3 


= 15; 






807 


ReservRepresentedByC ' I ' 3 


= 13; 


ReservRepresentedByC 'J' 3 :■ 


0; 


if eof (input) then goto 1 


808 


ReservRepresent edBy C'K' 3 


■ 0; 


ReservRepresentedByC 'L' 3 :» 


15; 


else OpenLine 


809 


ReservRepresent edByC'M* 3 


= 15; 






end 


810 


ReservRepresentedByC *N' 3 


■ 13; 


ReservRepresentedByC '0' 3 :« 


0; 


end; 


811 


ReservRepresentedByC 'P' 3 


= 15; 


ReservRepresentedByC'Q'3 := 


0; 


advance 


812 


ReservRepresentedByC 'R ' 3 


* 14; 


ReservRepresent edBy C'S' 3 :* 


6; 


end 


813 


ReservRepresentedByC "T " 3 


- 6; 


ReservRepresentedByC 'U* 3 :* 


H; 


else 


814 


ReservRepresentedByC 'V ' 3 


- 10; 


ReservRepresentedByC 'W' 3 :» 


6; 


if ch = '(' 


815 


ReservRepresentedByC 'X' 3 


■ 0; 


ReservRepresent edBy C'Y' 3 :« 


13; 


tFen 


816 


ReservRepresent edBy C 'Z ' 3 


- 0; 


reservedC13 : s empty; 




BTgin 


817 


reservedC383 : s empty; 


reservedC393 := empty; 




advance; 


818 


reservedC403 := empty; 






if ch « '*' 


819 


{} ch := 'A' { prevent optimizing 


'and' to empty - compile bug 


}; 


tFen 


820 


reservedC143 


= 'AND '; 


reservedC293 :- 'ARRAY • 




begin { comment } 


821 


reservedC333 


■ 'BEGIN '; 


reservedC 53 :* 'CASE \ 




advance; 


822 


reservedC123 


= 'CONST '; 


reservedC133 :« 'DIV •, 




repeat 


823 


reservedC 23 


= 'DO '; 


reservedC 63 :* 'D0WNT0 ' 




while ch <> '*' do 


824 


reservedC 43 


» 'ELSE '; 


reservedC 33 := 'END ' 




begin 


825 


reservedC193 


= ipiLE '; 


reservedC323 :« 'FOR ' 




if eoln(input) 


826 


reservedC363 


= 'FUNCTION '; 






then 


827 


reservedC 73 


= 'GOTO ' { 


to xref gotos set to empty 


j 


repeat 


828 


reservedC303 


= 'IF '; 


reservedC283 :- 'IN ' 


* 


CloseLine; 


829 


reservedC353 


= 'LABEL '; 


reservedC183 := 'MOD ' 


■ 


if eof(input) then goto 1 


830 


reserved C3 13 


= 'NIL '; 


reservedC223 :- 'NOT ' 




"eTse OpenLine 


831 


reservedC173 


= 'OF '; 






until not eo In (input) 


832 


{ if otherwise becomes reserved then flush left the next. 




else advance 


833 


reservedC 93 := ' OTHERWISE' 






end; 


834 


{ anticipating the revised standard }; 




advance 


835 


reservedC163 := 'OR '; 


reservedC213 := 'PACKED • 




until ch = •)'; 


836 


reservedC243 := 'PROCEDURE '; 


reservedC373 := 'PROGRAM ' 




advance 


837 


reservedC203 :- 'RECORD '; 


reservedC263 := 'REPEAT \ 




end 


838 


reservedC153 := 'SET '; 


reservedC233 :- 'THEN ' 




end 


839 


reservedC 83 := 'TO '; 


reservedC103 :* 'TYPE ' 




else advance 


840 


reservedC343 := 'UNTIL '; 


reservedC273 :- 'VAR ' 




end; 


841 


reservedC113 := 'WHILE '; 


reservedC253 := 'WITH ' 




CloseLine 


842 


end { initreserved } ; 






end; 
1: { terminate scan on eof while processing comment } 


843 
844 


procedure InitStates; 






end { scan }; 


845 













{$Y+ new segment } 

procedure initialize; 

procedure InitLetDig; 

const 
MinCharOrd = 0; 

{ ordinal of minimum character } 
DefaultMaxCharOrd = 64; 
{ BCD = 64 & ASCII = 127 & EBCDIC = 255 



var 



MaxCharOrd: 
ch: 



integer; 
char; 



procedure InitChrVaKStartChar, endchar: char; aval: integer); 



IcChar, 
ucChar: char; 

begin 

for IcChar := StartChar _to endchar do 
begin 

CliFCatagoryClcChar3 := IcLetter; 

ChrSort0rdClcChar3 := aval; ucChar := UpperCase(lcChar); 
ChrCatagoryCucChar3 := ucLetter; 
ChrSort0rdCucChar3 := aval - 1; aval := aval + 2; 
end 
end { initchrval }; 

begin { initletdig } 



846 
847 
848 
849 
850 
851 
852 
853 
854 
855 
856 
857 
858 
859 
860 
861 
862 
863 
864 
865 
866 
867 
868 
869 
870 
871 
872 
873 
874 
875 
876 
877 
878 
879 
880 



begin 

NextStateCinout, true3 := inout; 

NextStateCinout, false] := inwrkl; 

NextStateCinwrkl, true3 := wrklout; 

NextStateCinwrkl, false3 := wrk1wrk2; 

NextStateCwrklout, true3 :- wrklout; 

NextStateCwrklout, false3 := wrklout; 

NextStateCwrk1wrk2, true3 :* wrk2out; 

NextStateCwrk1wrk2, false3 := wrk2wrk1; 

NextStateCwrk2out, true3 := wrk2out; 

NextStateCwrk2out / false3 := wrk2out; 

NextStateCwrk2wrk1, true3 := wrklout; 

NextStateCwrk2wrk1, false3 := wrk1wrk2; 
end { initstates } ; 

{$Y+ new segment } 

procedure InitPredefined; 



state *.- inout; 



ch: char; 



for ch := '0' to '9' 
Predef Represent edBy C 
Predef Represent edBy C 
Predef Represent edBy C 
Predef Represent edBy C 
Predef Represent edBy C 
Predef Represent edBy C 
Predef Represent edBy C 
Predef Represent edByC 
Predef Represent edByC 
Predef Represent edByC ' 
Predef Represent edByC ' 



do PredefRepresentedByCch3 := 0; 

T"3 := 15; PredefRepresentedByC'B'3 

C'3 := 11; 

D'3 := 19; Predef RepresentedByC'E' 3 

F'3 := 3; PredefRepresentedByC'G'3 

H'3 := 0; PredefRepresentedByC'1'3 

J '3 := 0; Predef Represent edByC'K' 3 

L'3 := 13; PredefRepresentedByC'M'3 

N'3 := 19; PredefRepresentedByC'0'3 

P'3 := 18; PredefRepresentedByC'Q'3 

R'3 := 0; PredefRepresentedByC'S'3 

T'3 := 0; PredefRepresentedByC'U'3 



:= 9; 

- 5; 

- 0; 
s 3; 
= 16; 

■ 1; 

■ 0; 

- 0; 

- 15; 
= 17; 



PASCAL NEWS #17 



MARCH, 1980 



PAGE 45 



88t 




Predef RepresentedByC'V '3 := 


= 0; 


PredefRepresentedByC'W'3 := 10; 


991 


{} 


end; 




882 




Predef RepresentedByC'X '3 := 


■ 0; PredefRepresentedByC'Y'3 : = 0; 


992 






883 




PredefRepresentedByC'Z'3 := 


' 0; predefinedC13 := empty; 


993 




if i <= 32 then { contains file name part } 


884 




predefinedC 23 := empty; 


predefinedC 33 := empty; 


994 




begin 


885 




predef inedC42D := empty; 


predef inedC433 := empty; 


995 




j := 1; 


886 




predef inedC443 := empty; 


predefinedC453 := empty; 


996 




while ord(fspecCi3) > ordC ') do 


887 




predef inedC463 := empty; 


predef inedC473 := empty; 


997 




begin 


888 




predef inedC48] := empty; 




998 




namCj3 := fspecCi3; 


889 


{} 


ch := 'A' { prevent optimizing 'abs' to empty - compile bug }; 


999 




i := i + 1; j := j + 1; 


890 




predefined C33J 


= 'ABS 






1000 




jf_ (i > 32) or (j > 18) then goto 2; 


891 




predefinedC403 


= 'ARCTAN 






1001 




end; 


892 




predef inedC353 


= 'BOOLEAN 






1002 




. 


893 




predef inedC153 


= 'CHAR 






1003 




end; 


894 




predef inedC143 


= 'CHR 






1004 




end; 


895 




predefined C29] 


= 'COS 






1005 






896 




predefined C313 


= 'DISPOSE 






1006 






897 




predefinedC113 


= 'EOF 






1007 






898 




predefinedC281 


= 'E0LN 






1008 


{} 


procedure reeset (var f: text; var fspec: FileNames); 


899 




predef inedC263 


= 'EXP 






1009 






900 




predefinedC133 


= 'FALSE 




; predefinedC33 := 'GET '; 


1010 


{} 


var 


901 




predefinedC 8] 


= 'INPUT 




; predefinedC103 := 'INTEGER '; 


1011 


{} 


dev:devs; dir: dirs; nam: nams; 


902 




predefined C343 


= 'LN 




; predefinedC73 := 'MAXINT '; 


1012 






903 




predefined C323 


= 'NEW 






1013 


{} 


begin 


904 




predefinedC223 


- '0RD 




; predef inedC63 := 'OUTPUT '; 


1014 


{} 


SplitFileSpecif ication (fspec, dev, dir, nam); 


905 




predefined C383 


= 'PACK 






1015 


{} 


reset (f, nam, dir, dev); 


906 




predefinedC273 


= 'PAGE 






1016 


{} 


end; 


907 




predef inedC41 3 


* 'PRED 






1017 






908 




predef inedC21 3 


= 'PUT 






1018 






909 




predefined C233 


= 'READ 






1019 






910 




predefined C25] 


- 'READLN 






1020 






911 




predefinedC17] 


- 'REAL 




; predefinedC53 := 'RESET '; 


1021 


{} 


procedure reewrite (var f: text; var fspec: FileNames); 


912 




predef inedd 23 


= 'REWRITE 






1022 






913 




predefined C24] 


= 'ROUND 






1023 




var 


914 




predefined [37] 


= 'SIN 






1024 




dev:devs; dir: dirs; nam: nams; 


915 




predefined[18] 


= 'SQR 






1025 






916 




predefined[19] 


= 'SQRT 






1026 




begin 


917 




predefined [30] 


= 'SUCC 




; predefinedC43 := 'TEXT •; 


1027 




SplitFileSpecif ication (fspec, dev, dir, nam); 


918 




predefinedC 9] 


= 'TRUE 




predef inedC163 := 'TRUNC '; 


1028 




rewrite (f, nam, dir, dev); 


919 




predefined [39] 


- 'UNPACK 






1029 




end; 


920 




predefined [20] 


= 'WRITE 






1030 






921 
922 




predefined [36] 
end { initpredef : 


= 'WRITELN 
rned }; 






1031 
1032 




procedure GCML(var line: LineBuffer; var len: integer); 
extern { return command line in upper case }; 


923 








1033 






924 
925 


{$Y+ new segment } 




1034 
1035 
1036 




procedure quit; 


926 




begin { initperfect } 

InitReserved; InitStates; 






begin 


927 




InitPredefined; 


1037 




writeln(tty, ' Errors in Command Line'); 


928 




end { initperfect }; 




1038 




for cmlptr := 1 to cmllen do write(tty, cmllineCcmlptr]); 


929 








1039 




wrTteln(tty); writeln(ttyT; 


930 


{} 


procedure ConnectFiles; 




1040 




writeln(tty. 


<output file>=<input file> [<optons>3'); 


931 








1041 




writeln(tty, 


<options> ::='); 


932 


{} 


const 




1042 




writeln(tty, 


C- capitalize identifiers,'); 


933 


{} 


FSpecLeng = 32; 




1043 




writeln(tty, 


D+ display program,'); 


934 








1044 




writeln(tty, 


p- cross ref predefined ids.,'); 


935 


O 


type 




1045 




writeln(tty. 


T- terminal output (ids. only),'); 


936 


{} 


f specs = array [1 . 


. FSpecLeng3 of char; 


1046 




writeln(tty, ' W=132 width of output.'); writeln(tty); 


937 


{} 


FileSpecs = array [1 . 


. 23 of fspecs; 


1047 




writeln(tty); writeln(tty, ' HALT'); halt 


938 


{} 


extension = packed array C1 ..43 of char; 


1048 




end { quit } ; 


939 


{} 


FileNames = array C1 . 


. 323 of char; 


1049 






940 


{} 


devs = array C1 . 


. 53 oT~char; 


1050 




procedure NextClmCh; 


941 


H 


dirs = array C1 . 


. 93 oT char; 


1051 






942 


nams = array C1 . 


. 183 of char; 


1052 




begin 

if cmlptr >= cmllen then quit; cmlptr := cmlptr + 1; 


943 








1053 




944 


{} 


var 




1054 




CmlCh := cmllineCcmlptlT 


945 


O 


fspec: FileSpecs; 




1055 




end { nextcmlch } ; 


946 


{} 


flen: .. FSpecLeng; 


1056 






947 


O 


cmlptr: 1 ..80; 




1057 




procedure getfspecdnputOutput: integer; DefaultExtension: extension 


948 


{} 


CmlCh, 




1058 




); 


949 


{} 


CmdCh: char; 




1059 






950 





Dot Found: Boolean; 




1060 




procedure getnext; 


951 


{} 


pos: integer; 




1061 






952 
953 








1062 
1063 




begin 

if flen >= FSpecLeng then quit; 


954 








1064 




fspecClnput0utput3 Cflen3 := CmlCh; flen := flen + 1; 


955 




procedure SplitFileSpecif icatior 


(fspec: FileNames; 


1065 




NextClmCh; 


956 




var dev: devs; 


var dir: dirs; var nam: nams); 


1066 




end { getnext } ; 


957 




label 2; 




1067 






958 
959 




var 




1068 
1069 




begin { getf spec } 

fspecClnput0utput3 := ' '; 


960 




T: 1 .. 33; j: 1 .. 19; 




1070 




flen := 1; DotFound := false; 


961 








1071 




while CmlCh in C'A' .. 'Z', '0' .. '9', ':', 'C, '3', '.', ',', 


962 
963 




begin 

clev := ' •; dir := • 


7 


1072 
1073 




T'l do ~~ 
if CmlCh = '[* then repeat getnext; until CmlCh = '3* 


964 




nam := ' • 


i 


1074 




else 


965 








1075 




begin 

if not DotFound then DotFound :- CmlCh = '.'; getnext; 


966 




for i := 1 to 32 do 




1076 




967 




if fspecCi] >= 'a' ther 




1077 




end; 


968 




fspecCi3 := CHR (ordTfspecCi3) - 40B); 


1078 




if (flen > 1) and (not DotFound) then 


969 








1079 




for pos := 1 to 4 do 


970 




i := 1; 




1080 




begin 


971 




while not (fspecCi3 in C':' 


, 'C, '.', ';'3) and (i < 32) do 


1081 




fspecClnput0utput3 Cflen3 := DefaultExtensionCpos3; 


972 




begin 




1082 




flen := flen + 1; 


973 




~t" := i + 1; 




1083 




end; 


974 




end; 




1084 




end { getf spec } ; 


975 








1085 






976 




if fspecCi3 = ':' then { 


contains a device name } 


1086 




begin { connectf iles } 


977 




Begin 

for j := 1 to i do 




1087 




6CML(cmlline, cmllen); CmlCh := cmllineC13; cmlptr := 1; 


978 






1088 




cmllen := cmllen + 1; cmllineCcmllen3 := ' '; 


979 




if j <= 5 then devCj] 


:= fspecCj3; 


1089 




while CmlCh <> ' • do NextClmCh; while CmlCh = ' ' do NextClmCh; 


980 




i := i + 1; 




1090 




getfspecd, '.LST'); 


981 




end 




1091 




if flen = 1 


982 




else i := 1; 




1092 




then begin writeln(tty, ' No Output File Specified'); quit; end; 


983 








1093 




NextClmCh; while CmlCh = ' ' do NextClmCh; 


984 




if fspecCi3 = 'C then { 


contains a directory part } 


1094 




getf spec (2, '.PAS'); 


985 




begin 




1095 




j± flen = 1 


986 




j := 1; 




1096 




then begin writeln(tty, ' No Input File Specified'); quit; end; 
reeset (input, fspecC23); reewrite(output, fspecC13); 


987 




repeat 




1097 




988 




dirCj3 := fspecCi3; 




1098 




while ((cmlptr < cmllen) and (CmlCh <> '[')) do NextClmCh; 


989 




i := i + 1; j := j 


+ 1; 


1099 




if CmlCh = '[' 


990 




until (i > 32) or (j > 9) or (dirCj-13 = '3'); 


1100 




then 
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1101 
1102 
1103 
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1109 
1110 
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1114 
1115 
1116 
1117 
1118 
1119 
1120 
1121 
1122 
1123 
1124 
1125 
1126 
1127 
1128 
1129 



repeat 1130 

NextClmCh; 1131 

while (CmlCh = • •) or (CmlCh = ',') do NextClmCh; 1132 

jf CmlCh in C'C', 'dT 'P', 'T', 'W'3 1133 

then 1134 

begin 1135 

CmdCh := CmlCh; NextClmCh; 1136 

case CmdCh of_ 1137 

T': AUCapitals := CmlCh = ■ + '; 1138 

'D': DisplaylsActive := CmlCh = •+'; 1139 

'P': DoPredefined := CmlCh = •+'; 1140 

'T': 1141 

begin 1142 

terminal := CmlCh = '+'; 1143 

if terminal 1144 

then LineLength := DefaultTerminalWidth; 1145 

DisplaylsActive := not terminal; 1146 

end; 1147 

'W: 1148 

begin 1149 

if (CmlCh = ':') or (CmlCh = ' = ') then NextClmCh; 1150 

LTneLength := 0; 1151 

while CmlCh in CO' .. '9'] do 1152 

begin 1153 

LineLength := LineLength * 10 + ord(CmlCh) - ord 1154 

CO'); 1155 

NextClmCh; 1156 

end; 1157 

i± LineLength < (DefaultTerminalWidth - 8) 1158 



then LineLength := DefaultLpWidth; 



end; 
end; 
until CmlCh = '3'; 
end I cohnectf iles } ; 

} 



begin { initialize , 

CurrentLineNumber := 0; PageNumber := 0; 

LinesOnPage := LinesPerPage; AUCapitals := false; 

DisplaylsActive := true; DoPredefined := false; FreeStgPtr := 1; 

FreeltemPtr := nil; 

for ItemCnt := 1 to 80 do cmllineCltemCnt] := ' '; cmllen := 0; 

ItemCnt := 0; terminal - : 3 false; empty := ' '; 

for HshTbllndx := to HashTblSize - 1 do 
HashTableCHshTblIndx3.keyindx := 0; 

InitLetDig; InitPerfect; LineLength := DefaultLpWidth; 

today := empty; now := empty; 
{} ConnectFi les; date(today); time(now); 

wrk2active := false; 
end { initialize }; 

{$Y+ new segment } 

begin { xref } 

writeln(tty, '- CrossRef (80.2.1)'); initialize; 

OutputSection := listing; scan; OutputSection := idents; 

DumpTables; writeln(tty, *- End CrossRef); writeln(tty, • '); 
end { xref } . 
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{* Purpose: 

Library routines for string manipulation. 

* Author: 

.. Barry Smith 
Oregon Software 
2340 SW Canyon Road 
Portland Oregon 97201 

* Method: 

Uses fixed length arrays of characters. 

* Description of Routines: 

ten — Function. Returns string length. 

Clear — Blank fills a string. 

Concatenate — Appends one string to another. 
Search — Function. Returns substring position. 

Readstring — Read a string from a file. 
Writestring — Write a string to a file. 
Substring — Extract a substring from a string. 
Delete — Remove part of a string. 

Insert — Insert a string into a string. 

In several routines error processing is left for the 
user to provide. 

* Computer System: 

DEC PDP 11, OMSI Pascal version 1. 



const 

stringmax = 100; 

type 

string = record 

len: .. stringmax; 
ch: packed array C1 . 
end; 



stringmax] of char 



function len(s: string): integer; 
begin len := s.len end { len }; 
procedure clear( var s: string); 



i: integer; 



begin s.len := 0; 
clear }; 



for i := 1 to stringmax do s.chCiD := 



s.len := s.len + j; 



procedure concatenate (var_ s: string; t: string); 

var 

t", j: integer; 

begin 

TT~ s.len + t.len > stringmax 

TFTen j := stringmax - s.len { overflow } 

else j := t.len; 

for i := 1 to j do s.chCs.len + i3 := t.chCi3; 
end { concatenate 17 

function search(s, t: string; start: integer): integer 

var 

T, j: .. stringmax; 
uneq: boolean; 



begin 

tT" start < 1 then start := 1; 

TF (start + t.len > s.len + 1) or (t.len = 0) then search := 
else 
begin 

TT= start - 1; 
repeat 
TT^ i + 1; j := 0; 

repeat j := j + 1; uneq := t.chLj] <> s.chti + j - 13; 
until uneq or (j = t. 
len); 
until ( not uneq) or (i = s. 
len - tTTen + 1 ) ; 
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if uneq then search := 
end; 
end I search }; 



else search := 



procedure readstring (var f: text; var s: string); 

begin 

clear(s); 
with s do 

whi le ( not eoln(f)) and (len < stringmax) do 
begin len := len + 1; read(f, chClen3); end ; 
readln(f); 
end { readstring }; 

procedure writestring (var f: text; s: string); 

var 

i: integer; 

begin for i := 1 to s.len do write(f, s.chCi3) end { writestring }; 

procedure substring(var t: string; s: string; start, span: integer); 

var 

i: integer; 



begin 

if span < 



then begin span := - span; start := start - span end; 
jf start < 1 

then begin span := span + start - 1; start := 1 end; 
if start + span > s.len + 1 then span := s.len - start + 1; 
if span <= then clear(t) 
else 
begin 

for i := 1 t£ span do t.chCi3 := s.chCstart + i - 13; 
for i := span + 1 to stringmax do t.chCi3 := * '; 
t.len := span; 
end; 
end { substring }; 

procedure delete (var s: string; start, span: integer); 



i, limit: integer; 
begin 



span < 

TFen begin span := - span; start := start - span end; 
limit := start + span; vf start < 1 then start := 1; 
if limit > s.len + 1 then limit := s.len + 1; 
span := limit - start; 
if span > 
then 
begin 

for i := to s.len - limit do 

s.chCstart + i3 := s.chClimit + i3; 
for i := s.len - span + 1 to s.len do s.chCi3 := ' '; 
s.len := s.len - span; 
end; 
end I delete }; 

procedure insert ( var s: string; t: string; p: integer); 

var 

i, j: integer; 

begin 

rj_ t.len > 
then 

i± (p > 0) and (p <= s.len + 1) 
then 
Begin 

if s.len + t.len <= stringmax then s.len 

else s.len := stringmax { overflow }; 

for i := s.len downto p + t.len do s.chCi3 := s.chC 

if s.len < p + t.len then j := s.len 

else j := p + t.len - 1; 

for i := p to j do s.chCi] := t.chCi - p + 13; 



s.len + t.len 

t.len3; 



else { non-contiguous string } 
end { insert }; 



***************** 
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Purpose: 

Program computes Hankel functions of the first and second 
kinds for an integrel order and complex argument. 



Author: 

Q.M. Tran, School of Electrical Engineering, 
South Wales. 



University of New 



* Method: 

Hankel functions of a required order are calculated from 
corresponding Bessel functions of the first and second kinds. 
A backward recursive scheme is used in computing Bessel function 
of the first kind for a number of orders. 
These are then summed to give the two orders and 1 of 
Bessel function of the second kind, which in turn serve as 
starting point for finding a higher-order Bessel function of 
the second kind. 

* Description of parameters: 

p - integral order, where -max <= p <= max and max = 500. 

z - complex argument. 

fnl - Hankel function of the first kind. 

fn2 - Hankel function of the second kind. 

* Input: 

Program reads in an integer (p) and two real numbers (real and 
imaginary parts of z) . 

* Output: 

Arguments and values of the Hankel functions of the first 
and second kinds are returned. 

Warning message is given if any parameter exceeds specified 
limits or is outside range. 

* Limitations: 

- 500 <- p <» 500 , 

1.0E-5 <» modulus of z <= 377.0 , 

Imaginary part of z <« 50.0 , 

p must not be much greater than the modulus of z, otherwise 
exponent error in the computer (PDP 11/70) will occur. 

* Computer system: 

Program was run under UNIX Pascal (Berkeley - Version 1.2, 
May 1979) on DEC PDP 11/70. 

* Accuracy: 

Computed results were checked against published values over the 
following ranges: 

- 100 <« p <« 100 and 

real argument z = 0.1 - 100.0 , 

- 1 <« p <» 1 and 

complex argument z = (0.01,5 deg.) - (10.0,90 deg.) 

They were found to be accurate to at least 10 significant digits. 



program hankeUinput, output); 

Label 
1 i Exit to terminate program }; 

const 

TTm = 501; 

nax - 500; 

tpi = 0.6366197723675813 { 2.0 by pi }; 

euler = 0.5772156649015329; 

type 

complex = record 

re, im: real 
end; 



"T, k, n, m, I, p: integer; 
z, u, v, w, yo, y1, y2: complex; 
fn1, fn2, sum, esum, osum, norm, zero: complex; 
f: array CO .. limD of complex; 



procedure stop; 

begin 

goto 1 { halt } 
end { stop }; 



procedure ^readC var z: complex); 

begin 

read(z.re, z.im) 
end { cread }; 



procedure cwriteCvar z: complex); 

begin 

wntelnCC, z.re, ',', z.im, ')*) 
end { cwrite }; 



function mag (var z: complex): real; 

t Computes the modulus of a complex number } 

begin 

mag :- sqrt(sqr(z.re) + sqr(z.im)) 
end { mag }; 



procedure add(u, v: complex; var w: complex); 
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begin 

w.re := u.re + v. re; w.im := u.im + v.im 
end { add }; 



procedure sub(u, v: complex; var w: complex); 



w.re := u.re - v. re; w.im := u.im - v.im 
end { sub }; 



procedure mult(a: real; z: complex; var w: complex); 
I Multiplies a real with a complex } 

begin 

w.re := a * z.re; w.im := a * z.im 
end { mult }; 



procedure productCu, v: complex; var w: complex); 

begin 

w.re := (u.re * v. re) - (u.im * v.im); 

w.im := (u.re * v.im) + (u.im * v. re) 
end { product }; 



procedure quotient (u, v: complex; var w: complex); 



vr, vi, a, b, x1, x2, y1, y2, root: real; 

begin 

vr := abs(v.re); vi := abs(v.im); 

root := sqrt(2.0) * sqrt(vr) * sqrt(vi); a := vr + vi + root; 
b := vr + vi - root; 
if. (a = 0.0) or (b = 0.0) then 
begin 

writelnCW: dividing by in procedure quotient'); 
stop { Exit to terminate program }; 
end; 
x1 := u.re / a; x2 := v. re / b; y1 := u.im / a; 
y2 := v.im / b; w.re := x1 * x2 + y1 * y2; 
w.im := x2 * y1 - x1 * y2 
end { quotient }; 



procedure ccos(z: complex; var c: complex); 
{ Cosine of a complex } 

var 

ep, em, p, m: real; 

begin 

ep := exp(z.im); em := 1.0 / ep; p := ep + em; i : s ei • ep; 

ere := 0.5 * p * cos(z.re); c.im := 0.5 * m * sin(z.re) 
end { ccos }; 



procedure polar(u: complex; var v: complex); 
{ Writing a complex into polar form } 

const 

~"~pT"= 3.1415926535897932; 

begin 

if~(u.re = 0.0) and (u.im = 0.0) then 
begin 
writelnCW: conversion of in procedure polar'); 
stop { Exit to terminate program }; 
end; 
if (u.re = 0.0) and (u.im <> 0.0) then 
begin 

v.re := mag(u); v.im := pi / 2.0 
end 
else" 
begin 

v.re := mag(u); v.im :- arctan(u.im / u.re) 
end 
end Tpolar }; 



procedure cln(z: complex; var c: complex); 
{ Natural logarithm of a complex } 

var 
p: complex; 

begin 

polar(z, p); ere := In(p.re); c.im := p.im 
end { cln }; 



function order (z: complex): integer; 

{ Gives a starting and even order for recursive computation } 

var 

a: real; 
m: integer; 

begin 

a := mag(z); 

if a < 0.1 then m := 10 

else 

begin if a < 2.0 then m := 28 else m := round(1.2 * a ♦ 48.0) 
end; 
order := m; jj_ odd(m) then order := m + 1 
end { order }; 
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procedure sign(u: complex; var v: complex); 
I Changes the sign of a complex } 



end { sign }; 



procedure checkCz: complex); 
I Checks to see if the function argument is outside range } 

var 

a, b: real; 

begin 

a := abs(z.re); b := abs(z.im); 
rf_ ((a < 1.0E - 5) and (b < 1.0E - 5)) or 
<(b <> 0.0) and 7b~< 1.0E - 5)) then 
begin 

writeCW: small argument which causes exponent error = '); 
cwrite(z); stop { Exit to terminate program }; 
end; 
j± b > 50.0 then 
begin 
writeCW: argument with imaginary part outside range = '); 
cwrite(z); stop { Exit to terminate program }; 
end 
end "Tcheck }; 



procedure hankel12(u, v: complex; var w1, w2: complex); 
{ uanoines Bessel functions of theflrst & second kinds to give Hankel 
functions } 



begin 
wl.re := u.re - 
w2.re := u.re + 

end { hanke!12 }; 



wl.im 
w2.im 



u.im + v.re; 



begin { Hankel } 

read(p); n := abs(p); 
J_f n > s lim then 
begin 

writelnCW: required order ', p: 6, ' is outside the range (' 

max: 4, ' ,' , max: 4, •)'); 
stop { Exit to terminate program }; 
end; 
cread(z); 

check (z) { If z is outside range, exit to terminate program }; 
m := order(z); 
J_f m >= lim then 
begin 

writelnCW: starting order ', m: 6, 

• exceeds the specified maximum', max: 4); 
stop { Exit to terminate program }; 
end; 
zero. re := 0.0; zero.im := 0.0; sum := zero; esum := zero; 
osum := zero; fCm + 1] : = zero; fCm3.re := 1.0e - 30; 
fCm3.im := 0.0; 
for i := m downto 1 do 
begin 

quotient(fCi3, z, w); mult(2.0 * i, w, w); 
sub(w, fCi + 13, fCi - 13) 
end; 
k := m div 2; 

if abs(z.re) > 10.0 * abs(z.im) 
then 
begin 



291 for i := 1 to k do add(sum, fC2 * i3, sum); mult(2.0, sum, sum); 

292 addCsum, f COD, norm) 

293 end 

294 else 

295 begin 

296 for i := 1 to k do 

297 ~egin ~~ 

298 J_f odd(i) then add(osum, fC2 * i3, osum) 

299 else addCesum, f C2 * i3, esum) 

300 end; 

301 sub(esum, osum, sum); mult (2.0, sum, sum); 

302 addCsum, f COD, sum); ccos(z, u); quotient (sum, u, norm) 

303 end; 

304 _for i := to m do 

305 quotient (fCi 3, norm, fCi3) { Bessel functions of 1st kind }; 

306 esum := zero; osum := zero; I := 1; 

307 jf_ n = 

308 then 

309 begin { Ho } 

310 for i := 1 to k do 

311 begin 

312 I := - 1; multd / i, fC2 * i3, u); add(esum, u, esum) 

313 end; 

314 mult(2.0, esum, esum); mult(0.5, z, u); cln(u, u); 

315 u.re := u.re + euler; product(u, f COD, u); sub(u, esum, u); 

316 mult(tpi, u, yo) { Yo }; hankel12(fC03, yo, fn1, fn2); 

317 writeln; writeln; writeC Function argument = '); 

318 cwrite(z); writeln; 

319 writeC Hankel function of the first kind and order = '); 

320 cwrite(fnl); writeln; 

321 writeC Hankel function of the second kind and order = '); 

322 cwrite(fn2); writeln; writeln; 

323 stop { Exit to terminate program }; 

324 end { Ho } 

325 else 

326 begin { Hn, where n <> } 

327 for i := 1 to k do 

328 " Tegin ~~ ~~ 

329 I := - 1; multd / i, fC2 * i3, u); add(esum, u, esum); 

330 sub(fC2 * i - 13, fC2 * i + 13, v); multd / i, v, v); 

331 add(osum, v, osum); 

332 end; 

333 mult(2.0, esum, esum); mult(0.5, z, u); cln(u, u); 

334 u.re := u.re + euler; product(u, f COD, v); sub(v, esum, v); 

335 mult(tpi, v, yo) { YO }; product(u, fC13, v); 

336 quotient(fC03, z, w); sub(v, w, w); add(w, osum, w); 

337 mult(tpi, w, y1) { Yl }; i := 1; 

338 while i < n do 

339 T"ForwarcTrecursion to compute Yn, where n <> 0,1 } 

340 begin 

341 quotient(y1, z, u); mult(2 * i, u, u); sub(u, yo, y2); 

342 yo := y1; y1 := y2; i s* i + 1; 

343 end { Forward recursion }; 

344 if m < max then for i := m + 1 _to max do fCi3 := zero; 

345 hankel12(fCn37~yT, TnT, fn2); 

346 _H (p < 0) a£jd odd(p) then 

347 begin 

348 jsign(fn1, fnD; sign(fn2, fn2) 

349 end; 

350 writeln; writeln; writeC Function argument - '); 

351 cwrite(z); writeln; 

352 writeC Hankel function of the first kind and order ', p: 4, 

353 ' = '); 

354 cwrite(fnl); writeln; 

355 writeC Hankel function of the second kind and order ', p: 4, 

356 ' = '); 

357 cwrite(fn2); writeln; writeln; 

358 end { Hn }; 

359 1: 

360 end { Hankel }. 
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{* Purpose: 

Program computes a Bessel function of the first kind for an 
integral order and complex argument. 

* Author: 

Q.M. Tran, School of Electrical Engineering, University of 
New South Wales. 

* Method: 

Backward recurrence equation is employed to compute the function, 
starting at a higher order for which the Bessel function has a 
small value. The starting order is calculated using an 
empirical formula. When the function argument is mainly real, 
normalization is to unity. If it is mainly imaginary, 
normalization involves cosine of the complex argument. 

* Description of parameters: 

p - integral order, where -max <= p <= max and max = 500 

z - complex argument. 

fn - Bessel function of z and order p. 

* Input: 

Program reads in an integer (p) and two real numbers 
(real and imaginary parts of z) . 

* Output: 

Argument & value of the Bessel function of the first kind 
are returned. Warning message is given if any parameter 
exceeds specified limits or is outside range. 

* Limitations: 

- 500 <= p <= 500, 

1.0e-5 <= modulus of z <= 377.0, 
Imaginary part of z <= 50.0. 

* Computer system: 

Program was run under UNIX Pascal (Berkeley - Version 1.2, 
May, 1979) on DEC PDP 11/70. 

* Accuracy: 

Computed results were checked against published values over 
the following ranges: 

- 100 <= p <= 100 and 0.1 <= modulus of z <= 100.0. 

They were found to be accurate to at least 8 decimal digits. } 



program bessell (input, output); 

Label 
1 t Exit to terminate program }; 

const 

CTm = 501; 
max = 500; 

type 

complex = record 

re, im: real 
end; 

var 

i, k, n, m, p: integer; 

z, w, fn, sum, esum, osum, norm, zero: complex; 

f: array CO .. Iim3 of complex; 



procedure stop; 

begin 

goto 1 { halt } 
end { stop }; 



procedure cread( var z: complex); 

begin 

read(z.re, z.im) 
end { cread }; 



procedure cwriteCvar z: complex); 

begin 

writelnC (', z.re, ',', z.im, ')') 
end { cwrite }; 



function mag( var z: complex): real; 

{ Computes the modulus of a complex number } 

begin 

mag := sqrt (sqr(z.re) + sqr(z.im)) 
end { mag }; 



procedure add(u, v: complex; var w: complex); 

begin 

w.re := u.re + v. re; w.im := u.im + v.im 
end {add }; 



procedure sub(u, v: complex; var w: complex); 

begin 

w.re := u.re - v. re; w.im := u.im - v.im 
end { sub }; 



procedure mult(a: real; z: complex; var w: complex); 
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{ Multiplies a real with a complex } 

begin 

w.re := a * z.re; w.im := a * z.im 
end { mult }; 



procedure quotient (u, v: complex; var w: complex); 



vr, vi, a, b, x1, x2, y1, y2, root: real; 

begin 

vr := abs(v.re); vi := abs(v.im); 

root := sqrt(2.0) * sqrt(vr) * sqrt(vi); a := vr + vi ♦ root; 
b := vr + vi - root; 
2± (a = 0.0) or (b = 0.0) then 
begin 

writelnCW: dividing by in procedure quotient*); 
stop { Exits to terminate program }; 
end; 
x1 := u.re / a; x2 := v. re / b; y1 := u.im / a; 
y2 := v.im / b; w.re := x1 * x2 + y1 * y2; 
w.im := x2 * y1 - x1 * y2 
end { quotient }; 



procedure ccosCz: complex; var c: complex); 
{ Cosine of a complex } 

var 

ep, em, p, m: real; 

begin 

ep := exp(z.im); em := 1.0 / ep; p := ep + em; m := em - ep; 

ere := 0.5 * p * cos(z.re); c.im := 0.5 * m * sin(z.re) 
end { ccos }; 



function order(z: complex): integer; 

{ Gives a starting and even order for recursive computation } 

var 

a: real; 
m: integer; 

begin 

a := mag(z); 

j_f a < 0.1 then m := 10 

else 

begin if a < 2.0 then m := 28 else m := round(1.2 * a + 48.0) 
end; 
order := m; vf odd(m) then order := m + 1 
end { order }; 



procedure sign(u: complex; var v: complex); 
{ Changes the sign of a complex } 

begin 

v.re := - u.re; v.im := - u.im 
end { sign }; 



procedure checkCz: complex); 

{ Checks to see if the function argument is outside range } 

var 

a, b: real; 

begin 

a := abs(z.re); b := abs(z.im); 

_if ((a < 1.0e - 5) and <b < 1.0e - 5)) or ((b <> 0.0) and (b < 1.0e 

- 5)) 
then 
begin 

writeCW: small argument which causes exponent error = '); 
cwrite(z); stop { Exits tc terminate program }; 
end; 
if b > 50.0 then 



'); 



begin 

writeCW: argument with imaginary part outside range ; 
cwrite(z); stop { Exits to terminate program }; 
end 
end { check } ; 



begin { Bessell } 

read(p); n := abs(p); 
if n >= lim then 
begin 

writelnCW: required order ', p: 6, ' is outside the range (', - 

max: 4, ',', max: 4, ')*); 
stop { Exits to terminate program }; 
end; 
cread(z); 

check (z) { If z is outside range, exit to terminate program }; 
m := order(z); 
if m >= lim then 
begin 

writelnCW: starting order ', m: 6, 

' exceeds the specified maximum', max: 4); 
stop { Exits to terminate program }; 
end; 
if n >= m 
then 
begin 

writeln; writeln; writeC Function argument = '); 

cwrite(z); writeln; 

writelnC Bessel function of the first kind and order ', p: 4, 
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/ )'); 
write!, n; 



zero.im := O.O; 
fCm + 13 := zero; 



221 ' = ( 

222 writeln; 

223 end; 

224 zero. re := 0.0, 

225 osum := zero; 

226 fCmD.im := 0.0; 

227 for i := m downto 1 do 

228 begin 

229 quotient(fCi3, z, w); 

230 sub(w, fti + 13, fCi 

231 end; 

232 k := m d_w 2; 

233 if abs(z.re) > 10.0 * abs(z.im) 

234 Wen 

235 begin 

236 for i := 1 to k do add(sum, fC2 

237 add (sum, fCoT, norm) 

238 end 



stop { Exits to terminate program }; 



sum := zero; esum := zero; 
fCm3.re := 1.0e - 30; 



mult(2.0 
13) 



w); 
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13, sum); mult(2.0, sum, sum); 
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else 
begin 

for i ;= 1 to k do 
begin 

if odd(i) then add(osum, fC2 * i3, osum) 
else add(esum, f C2 * i3, esum) 



subTesum, osum, sum); mult(2.0, sum, sum); 

add(sum, fC03, sum); ccos(z, w); quotient (sum, w, norm) 
end; 
quotient(f Cn3, norm, fn); 

_vf (p < 0) and (odd(p)) then sign(fn, fn); writeln; writeln; 
writeC Function argument = '); cwrite(z); writeln; 
writeC Bessel function of the first kind and order ', p: 4, ' • 



cwrite(fn); writeln; writeln; 1: 



255 end { Bessell }. 
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{* Purpose: 

Program computes a Bessel function of the second kind for an 
integral order and complex argument. 

* Author: 

Q.M. Tran, School of Electrical Engineering, University of New 
South Wales. 

* Method: 

Initially, a number of Bessel functions of the first kind are 
generated by backward recursion. These are then summed to give 
the two orders and 1 of the Bessel function of the second kind. 
Using forward recurrence relation based on these two orders, 
a higher order is calculated. 

* Description of parameters: 

p - integral order, where -max <= p <= max and max = 500. 

z - complex argument. 

fn - Bessel function of z and order p. 

* Input: 

Program reads in an integer (p) and two real numbers (real and 
imaginary parts of z) . 

* Output: 

Argument & value of the Bessel function of the second kind are 
returned. Warning message is given if any parameter exceeds 
specified limits or is outside range. 

* Limitations: 

- 500 <= p <- 500 , 

1.0e-5 <= modulus of z <= 377.0 , 

Imaginary part of z <= 50.0 , 

p must not be much greater than the modulus of z, otherwise 

exponent error in the computer (PDP 11/70) will occur. 

* Computer system: 

Program was run under UNIX Pascal (Berkeley - Version 1.2, 
May 1979) on DEC PDP 11/70. 

* Accuracy: 

Computed results were checked against published values over the 
following ranges: 

- 100 <= p <= 100 and 

real argument z = 0.1 - 100.0 , 

- 1 <= p <= 1 and 

complex argument z = (0.01,5 deg.) - (10.0,90 deg.) . 

They were found to be accurate to at least 10 significant digits. } 
program bessel2(input, output); 

label 
TT Exit to terminate program }; 

const 

[Tin = 501; 

max = 500; 

tpi = 0.6366197723675813 { 2.0 by pi }; 

euler = 0.5772156649015329; 

type 

complex = record 



i, k, n, m, I, p: integer; 

z, u, v, w, yo, y1, y2: complex; 

fn, sum, esum, osum, norm, zero: complex; 

f: array CO .. Iim3 of complex; 



procedure stop; 

begin 

goto 1 { ha 
end { stop }; 



procedure cread( var z: complex); 

read(z.re, z.im) 
end { cread J; 



procedure cwrite( var z: complex); 



writelnC (', z.re, 
end { cwrite }; 



function mag( var z: complex): real; 

{ Computes the modulus of a complex number } 

begin 

mag := sqrt(sqr(z.re) + sqr(z.im)) 
end { mag }; 
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procedure add(u, v: complex; var w: complex); 
re; w.im := u.im + v.im 



begin 

w.re := u.re 
end { add }; 



procedure sub(u, v: complex; var w: complex); 

begin 

w.re := u.re - v. re; w.im := u.im - v.i 
end { sub }; 



procedure mult(a: real; z: complex; var w: complex); 
{ Multiplies a real with a complex } 



begin 

w.re := a * z.re; 
end { mult }; 



w.im := a * z.im 



procedure product(u, v: complex; var w: complex); 

begin 

w.re := (u.re * v. re) - (u.im * v.im); 

w.im := (u.re * v.im) + (u.im * v. re) 
end { product }; 



procedure quotient (u, v: complex; var w: complex); 

var 

vr, vi, a, b, x1, x2, y1, y2, root: real; 



: vr + vi + root; 



vr := abs(v.re); vi := abs(v.im); 
root := sqrt(2.0) * sqrt(vr) * sqrt(vi); 
b := vr + vi - root; 
i± (a = 0.0) or (b = 0.0) then 

begin 

writelnCW: dividing by in procedure quotient'); stop; 

{ Exit to terminate program } 

end; 
x1 := u.re / a; x2 := v. re / b; y1 := u.im / a; 
y2 := v.im / b; w.re := x1 * x2 + y1 * y2; 
w.im := x2 * y1 - x1 * y2 
end { quotient }; 



procedure ccos(z: complex; var c: complex); 
{ Cosine of a complex } 



var 

ep, em, p, 



real; 



begin 

ep := exp(z.im); em := 1.0 / ep; p := ep + em; m := e 
ere := 0.5 * p * cos(z.re); c.im := 0.5 * m * sin(z.re) 

end { ccos }; 



procedure polar(u: complex; var v: complex); 
I Writing a complex into polar form } 

const 

pi = 3.1415926535897932; 

begin 

vT"(u.re = 0.0) and (u.im = 0.0) then 
begin 

writelnCW: conversion of in procedure polar'); stop; 
{ Exit to terminate program } 
end; 
if (u.re = 0.0) and (u.im <> 0.0) then 
begin 

v.re := mag(u); v.im := pi / 2.0 
end 
else 
begin 

v.re := mag(u); v.im := arctan(u.im / u.re) 
end 
end { polar }; 



procedure cln(z: complex; var c: complex); 
{ Natural logarithm of a complex } 

var 

p: complex; 



begin 

polar(z, p); ere := In(p.re); 

end { cln }; 



c.im := p.im 
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198 function order(z: complex): integer; 

199 { Gives a starting and even order for recursive computation } 
200 

var 

a: real; 
m: integer; 



begin 

a := mag(z); 

if a < 0.1 then m := 10 

else 

begin if a < 2.0 then m := 28 else m := round(1.2 * a + 48.0) 
end; 
order := m; jj_ odd(m) then order := m + 1 
end { order }; 
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215 procedure signCu: complex; var v: complex); 

216 { Changes the sign of a complex } 
217 

218 begin 

219 v.re := - u.re; v.im := - u.im 

220 end { sign }; 

221 
222 

223 procedure check(z: complex); 

224 I Checks to see if the function argument is outside range } 
225 
226 
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245 
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247 

248 begin { Bessel2 } 

249 read(p); n := abs<p); 

250 if n >= lim then 

251 "" "begin 

252 wrTtelnCW: required order ', p: 6, ' is outside the range (', - 

253 max: 4, ','/ max: 4, ')'); 

254 stop; 

255 { Exit to terminate program } 

256 end; 

257 cread(z); check(z); 

258 { If z is outside range, exit to terminate program } 

259 m := order(z); 

260 if m >= lim then 

261 " "begin 

262 writelnCW: starting order ', m: 6, 

263 ' exceeds the specified maximum', max: 4); 

264 stop; 

265 { Exit to terminate program } 

266 end; 



var 

a, b: real; 

begin 

a := abs(z.re); b := abs(z.im); 

if ((a < 1.0e - 5) and (b < 1-0e - 5)) or ((b <> 0.0) and (b < 1.0e 

- 5)) 
then 
Begin 

wnteCW: small argument which causes exponent error = '); 
cwrite(z); stop; 
{ Exit to terminate program } 
end; 
if"B"> 50.0 then 



wnteCW: argument with imaginary part outside range = '); 
cwrite(z); stop; 
{ Exit to terminate program } 
end 
end { check }; 
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sum := zero; esum := zero; 
fCmD.re := 1.0e - 30; 



mult(2.0, sum, sum); 



zero. re := 0.0; zero.im := 0.0; 
osum := zero; fCm + 13 := zero; 
fCmD.im := 0.0; 
for i : s m downto 1 do 
begin 

quotient(fCi3, z, w); mult(2.0 * i, w, w); 
sub(w, fCi + 13, fCi - 13) 
end; 
k := m div 2; 

if abs(z.re) > 10.0 * abs(z.im) 
then 
begin 

for i := 1 tp_ k c[o addCsum, fC2 * i3, sum); 
add (sum, fC03, norm) 

end 
else 
begin 
?or i := 1 to k do 
"Begin 

if odd(i) then addCosum, f C2 * i3, osum) 
eTse add(esum, f C2 * i3, esum) 
end; 
sub (esum, osum, sum); mult(2.0, sum, sum); 
add(sum, fC03, sum); ccos(z, u); quotient (sum, u, norm) 
end; 
for i : a to m do quotient(f Ci3, norm, f Ci3); 
{ Bessel functions of 1st kind } 
esum := zero; osum := zero; I := 1; 
if n = 
TFen 

Begin { Yo } 

for i := 1 to k do 
begin 

I := - I; multd / i, fC2 * i3, u); add(esum, u, esum) 
end; 
mult(2.0, esum, esum); mult(0.5, z, u); cln(u, u); 
u.re := u.re + euler; product(u, fC03, u); sub(u, esum, u); 
mult(tpi, u, yo); fn := yo; writeln; writeln; 
writeC Function argument = '); cwrite(z); writeln; 
writeC Bessel function of the second kind and order = '); 
cwrite(fn); writeln; writeln; stop; 
{ Exit to terminate program } 
end { Yo } 
else 
begin { Yn where n <> } 
for i := 1 to k do 
begin 

I := - I; multd / i, fC2 * i3, u); add(esum, u, esum); 
sub(fC2 * i - 13, fC2 * i + 13, v); multd / i, v, v); 
add(osum, v, osum); 
end; 
mult (2.0, esum, sum); mult(0.5, z, u); cln(u, u); 
u.re := u.re + euler; product(u, fC03, v); sub(v, esum, v); 
mult(tpi, v, yo); 
{ Yo } product(u, fCi3, v); 
quotient Cf COD, z, w); sub(v, w, w); add(w, osum, w); 
mult(tpi, w, y1); 
{ Yl } i := 1; 
while i < n do { Forward recursion } 

quotient(y1, z, u); mult(2 * i, u, u); sub(u, yo, y2); 
yo := y1; y1 := y2; i := i + 1; 
end; 
{ Forward recursion } 

fn := y1; if (p < 0) and odd(p) then sign(fn, fn); writeln; 

writeln; wTTteC Function argument = '); cwrite(z); 

writeln; 

writeC Bessel function of the second kind and order ', p: 4, 

• = •); 
cwrite(fn); writeln; writeln 
end; 
{ YnT" 
1: 
end { bessel2 }. 



iVlV^TlVlVlVlVlV 



PASCAL NEWS #17 



MARCH, 1980 



PAGE 52 



1 

2 
3 

4 
5 

6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 
55 
56 
57 
58 
59 
60 
61 
62 
63 
64 
65 
66 
67 
68 
69 
70 
71 
72 
73 
74 
75 
76 
77 
78 
79 
80 
81 
82 
83 
84 
85 
86 
87 
88 
89 
90 
91 
92 
93 
94 
95 
96 
97 
98 
99 
100 
101 
102 
103 
104 
105 
106 
107 
108 
109 
110 



{* Purpose: 

Library routines to manipulate character strings in Pascal. 

* Author: 

Judy N. Bishop, Computer Science Division, University of the 
Witwatersrand, Johannesburg 2001, South Africa. 

* Description of routines: 

String Initialize — set up the free space list ... called first 
and once. 

— Internal error reporting routine. 

— Internal string allocation routine. 

— Internal string deallocation routine. 

— User callable. Initialize a string for writing. 

— User callable. Initialize a string for reading. 

— User callable function. 
Returns string's length. 

— User callable function. 
True if at end of string. 

— Internal string character put routine. 

— Internal string character get routine. 

— User callable string creation routine. 

— User callable string removal routine. 

— User callable read string routine. 

— User callable write string routine. 

— User callable trailing blank removal routine. 

— User callable string assignment routine. 

— User callable function returning the 
relationship between two strings. 

— User callable assignment of alfa to string. 

— User callable assignment of char to string. 



StringError 

News 

Disposes 

Rewrites 

Resets 

Length 

Bofs 

Puts 

Gets 

Opens 

Closes 

Reads 

writes 

Suppress 

Assign 

Compare 

AlfaToString 
CharToString 



An implementation of character string primitives using Pascal's 
dynamic storage allocation facilities. The routines follow Arthur 
Sale's recommendation that strings be treated as sequences of 
characters. Pascal sequences are processed by file routines, thus 
these string routines use similar names for similar functions. 

* Computer System: 

IBM 360/370 AABC Pascal compiler version 1.2. 

* References: 

J. M. Bishop, "Implementing Strings in Pascal', "Software - 
Practice and Experience", 9(9), 779-788 (1979). 
A. H. J. Sale, 'Strings and the sequence abstraction in Pascal 1 , 
"Software - Practice and Experience", 9(8), 671-683 (1979). 



program stg (input, output); 

const 

chunksize = 32; 
alfalen = 10; 



type 



natural = .. maxint; 
text= file of char; 
alfa- packecTarray C1 
chunkptr - "chunk; 
chunk = record 



alfalen] of char; 



string 



char 
end; 
record 



next: chunkptr; 
line: packed array C1 



chunksize] of 



w: char; 
length: natural; 

.. chunksize; 



position: 

start, 

current: 

chunkno: 

status: 



chunkptr; 

natural; 

(reading, writing, notready) 



: (before, beforeorequalto, equalto, afterorequalto, 
after, notequalto); 



avail: chunkptr; 
procedure stringinitialize; 
begin avail := nil; end; 
procedure stringerror(n: natural); 



writeln; 

case n of_ 
T7 write( 
2: write( 
3: write( 
4: write( 



writelnC **** execution error in string library ****•); 



put attempted in read state '); 

get attempted in write state '); 

get attempted beyond end of string 

delete portion bigger than string ' 
5: writeC extract portion bigger than string 
6: writeC inserting beyond end of string ') 



end; 

writelnC ****'); 
{} halt 
end { stringer ror }; 

procedure news( var p: chunkptr); 



begin 

if avai I = 
then 
begin 
new(p); 



111 { undefined } 

112 end 

113 else begin p := avail; avail := avail*. next end; 

114 enTTnews j; 
115 

116 procedure disposes(p: chunkptr); 
117 

118 begin p*. next := avail; avail : s p; end; 
119 

120 procedure rewrites (var s: string); 
121 

begin 
with s do 

if start *= nil 

Tnen begin news(start); start*. next :* nil; end; 
current := start; position := 0; chunkno :- 0; 
length := 0; status := writing 
end 
end "{""rewrites }; 



122 

123 

124 

125 

126 

127 

128 

129 

130 

131 

132 procedure resets (var s: string); 

133 

var 

c: chunkptr; 



c : s current". next; 
disposes (c); c 
0; 



= current 



134 

135 

136 

137 

138 

139 

140 

141 

142 

143 

144 

145 

146 

147 

148 

149 

150 

151 

152 

153 

154 

155 

156 function length(s: string): natural; 

157 

158 begin resets(s); length := s. length; end; 

159 

160 function eofs(s: string): boolean; 

161 

162 begin 

163 with s do eofs := (length + 1) = chunkno * chunksize + position; 

164 encTTeofs - }; 
165 

166 procedure puts( var s: string); 
167 

b egin 

with s do 



begin 

with s do 
begin 

if status = writing 
then 
"Ibegi n 

length := length + position; 
current*. next := nil; 
while c <> nil do 

begin current := c*.next; 
end 
end; 
current := start; position := 1; chunkno 
status := reading; 

vf current <> nil then w := current*. lined] else w := ' '; 
{ when reset done on an empty string } 
end 
end "Presets }; 



begin 

rF~status = reading then stringerrord); 
T7 position = chunksize 
then 
begin 

if current". next = nil then 
begin 

news(current".next); current". next". next := nil; 
end; 
current := current". next; chunkno := chunkno + 1; 
length := length + chunksize; position := 1; 
end 
else position := position + 1; 
current*. lineCposition] := w; w := ' '; 
end 
end T~puts }; 



168 

169 

170 

171 

172 

173 

174 

175 

176 

177 

178 

179 

180 

181 

182 

183 

184 

185 

186 

187 procedure gets(var s: string); 

188 

begin 

with s do 
begin 

if status = writing then stringerror(2); 
Tf eofs(s) then stringerror(3); 
if position = chunksize 
Th~en 
begin 

current := current". next; chunkno := chunkno + 1; 
position := 1 
end 
else position := position + 1; 

if current <> ni I then w := current". lineCposition] 
else w := ' '; 
{ when the eof coincides with the end of a chunk. } 
end 
end 1 gets }; 



189 

190 

191 

192 

193 

194 

195 

196 

197 

198 

199 

200 

201 

202 

203 

204 

205 

206 

207 procedure opens( var s: string); 

208 

begin 

with s do 
begin 

length := 0; chunkno := 0; position := 0; 
current := ni I; status := notready; w := 
end 

end Topens }; 



nil 



with p" do for i := 1 to chunksize d_o lineCi] : = 



209 

210 

211 

212 

213 

214 

215 

216 

217 procedure closes( var s: string); 

218 

219 begin 

220 with s do 



start 
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while start <> nil do 
begin 

current := start". next; disposes(start); 
start := current 
end ; 
end { closes }; 

procedure reads( var from: text; var s: string); 
1 reads until an end-of-line. 1 

begin 

rewrites(s); _i_f_ eoln(f rom) then get(from); 
whi le not eoLn(from) do 

begin s.w := from"; puts(s); get(from); end; 

end { reads }; 

procedure writes( var onto: text; s: string); 

begin 

resets(s); 

whi le not eofs(s) do begin writeConto, s.w); gets(s); end 
end I writes }; 

procedure suppress( var s: string); 
"I removes trail ing"~DTanks. } 

const 

space = ' '; 



spaces: boolean; 
mark, 



I: natural; 
mark := 0; 



resets(s); spaces := false; 



space 



begin 

I := length(s); 
for i := 1 to I do 
begin 
if s.w 
then 
begin 

if not spaces then begin spaces := true; mark := i end 
encP 
else begin spaces := false; mark := 0; end; 
gets(s) 
end; 
if mark > then s. length := mark - 1; resets(s); 
ericT t suppress } ; 

procedure assignC var s1 : string; s2: string); 

begin 

rewrites(sl); resets(s2); 



275 while not eofs(s2) d£ 

276 begin sl.w := s2.w; puts(s1); gets(s2); end; 

277 end t assign }; 
278 

279 function compare(s1: string; r: relation; s2: string): boolean; 
280 

var 

less, 
equal: boolean; 
ls1, 
ls2: natural; 



281 
282 
283 
284 
285 
286 
287 
288 
289 
290 
291 
292 
293 
294 
295 
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299 
300 
301 
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304 



begin 

IsT := length(sl); ls2 := length(s2); resets(sl); resets(s2); 

pnual ;= I <;1 s Is?: less : = false; 

\ m less) and not eofs(s1) and not eofs(s2) dho 
s2.w; less := sl.w < s2.w; gets(s1); 



equal := s1 
gets(s2) 
end; 
case r oi_ 
before: compare := less; 
beforeorequalto: compare := less or equal; 
equalto: compare := equal; 
afterorequalto: compare := not less ojr equal; 
after: compare := not less; 
notequalto: compare := not equal 
end; 
end"T compare }; 



JU4 

305 procedure alf atostring(a: alfa; var s: string); 
306 

const 

space = • '; 



307 
308 
309 
310 
311 
312 
313 
314 
315 
316 
317 
318 
319 
320 
321 
322 
323 



i: natural; 
state: (scanning, ended, spacefound); 



begin 

rewrites(s); 



i := 1; state := scanning; 



repeat 

if i > alfalen then state := ended 



else 

— aLU 

else begin s.w : = aTTT; 

unti I state <> scanning; 
end { alfatostring }; 



space then state := spacefound 

puts(s); i := i + 1 end 



324 procedure chartostring(c: char; var s: string); 
325 

326 begin rewrites(s); s.w := c; puts(s) end; 

327 ~"^ 

328 begin end . 



&&&&&&& ft 
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CONFORMANT ARRAYS IN PASCAL 

by A*H*J*Sale 

University of Tasmania 

(at the request of Andy Mickel) 



1 # CONFORMANT ARRAYS AND THE NEW STANDARD. 

The draft proposal for an ISO Standard for Pascal contains within it a 
definition of what I shall call a "conformant array parameter" * The basic 
concept is that of a parameter specification which allows a formal- 
parameter to assume the values and types of different actual array- 
parameters * 

How did the draft Standard acquire this feature? And why? 

2* PPggSURE qRQVP? 

During the preparation of the draft Standard, a considerable amount of 
public comment was received by the sponsoring body, BSI, and the chairman 
of its Pascal Committee, Tony Addyman* (I seem to recall a figure of 
10kg*) A significant amount of this was devoted to the problem of writing 
general procedures to sort and perform other array operations, inevitably 
leading either to suggestions of a full dynamic array facility, or some 
sort of conformant array parameter* 

Of course, contributors to Pascal News have not been idle in this regard 
either* Many suggestions for conformant array parameters have been 
received; some good, some not* It is clear that this is perceived by many 
to be a deficiency in the language, though there are quite good arguments 
to support the view that it is only a deficiency viewed in a particular 
way* Correct or not, the perception has led to pressure being applied to 
the Pascal Committee to put a feature of this sort in the draft, the 
Numerical Algorithms Group (NAG) at Oxford being an important example. 

However, this pressure had not had an effect by the time of the publication 
of the third Working Draft (N462) widely published last year* Then, two 
critical pressures were applied to the Committee by N* Wirth and 
C*A*R*Hoare (independently) supporting the view that now was the time to 
add a conformant array feature to Pascal* It seems safe to assume that in 
the absence of pressure from such quarters the urge to add to Pascal would 
have been successfully resisted by BSI* 



1* PROPOSALS 

The proposals put forward by way of defining a conformant array feature 
have been many and varied. Some have been strange in their exploitation of 
minor aspects of Pascal, and many others have been obsessed by syntax to 
the exclusion of what the construct should mean* It is quite clear, even 
before you look seriously, that the addition of conformant arrays to Pascal 
is not a trivial task* 

The BSI Pascal Committee accordingly had to choose something to satisfy the 
pressures from the joint designers of the language* They rejected the 
silly suggestions of course, and chose to put in the document which went to 



Turin (N510) a considerably modified version of a scheme which seemed to 
originate with Jacobi. Subsequently, it became clear that there were 
better possibilities, and BSI withdrew support for its own draft, in favour 
of an improved one, now incorporated in the Draft Proposal. This scheme, 
which seems to have originated with N.Wirth, has been examined by both 
opponents and proponents of the addition in order to ensure that at least 
if there is to be an addition, it should be the best one possible. That is 
my own position. 

The key idea behind the current proposal is that it preserves the 
abstraction of an array as a complete mapping, and incorporates a number of 
"compile-time" checks on the validity of actual calls. The cost is that of 
introducing what the draft proposal calis a "schema"; or in other words a 
specification which is not a type but a rule for identifying and 
constraining a set of types. Thus the type of a formal conformant-array- 
parameter is not known from its declaration, but is supplied by each call. 
The consequences are very simple outside this one point, especially in 
defining parameter-list congruity which many other proposals make very 
heavy weather of indeed. 

1. TURIN 

At Turin, the site of the very first computer conference ever, there was a 
considerable amount of discussion of the conformant array proposal. 
Opposition to the proposal was stated by the US , and one or two other 
people, but there was clearly a substantial majority which would accept the 
inclusion of such a feature, and many indeed welcomed it. Consequently, 
the feeling of the experts group was recorded as being in favour of some 
form of conformant array parameter being in the first Standard. 

Discussion then turned on the form of the parameter mechanism, with the 
possibilities being the BSI original, the redraft now incorporated, and an 
improved Jacobi-like proposal. Conformant array parameters took over two 
hours of technical discussion (about 12$ of the total), and also ran into 
dinner, breakfast and a coffee-break. However, it is useful to realize 
that the Turin meeting perceived this as an important issue, but not of 
over-riding importance. 



5.. TIMELINESS 

Part of the pressure to make this feature appear in the Draft Standard 
arises from a desire to have important numerical algorithms translated into 
Pascal, and the language used in this area now dominated by Fortran. But 
simply because this pressure is present, many implementors have already 
inserted a feature of this general type into their implementations, and 
they differ very widely. Not surprizingly , not many implementors think 
much about the abstractions behind their extensions, or perhaps they borrow 
extensions. The signs are there that if conformant array parameters are 
not standardized now, they may as well never be for all the good it will 
do. 



Speaking personally, I had had six new implementors call me in the last 
month, and all of them have asked for guidance on how they should implement 
conformant array parameters. Such interest by new commercial 
implementations is significant; however the existing implementations are 
likely to be harder to bring into any sort of conformance. 



Reluctantly, because I was not an original supporter of conformant arrays, 
I have been convinced that both timeliness and utility require the action 
that was taken at Turin. I think the inclusion is warranted. 

6. CURRENT STATUS 

To keep readers of Pascal News informed, I reproduce some pieces of the 
draft proposal as they relate to conformant array parameters. It can be 
seen that the addition is entirely localized within the parameter list, 
except for the addition of one item to 'factor' (and no need even to write 
anything about it in the accompanying text) . The conformant array 
parameter schema is well-crafted so that it hangs together as an integrated 
whole, and the reasons for most of the statements will be clear after some 
thought. 

The exact syntax may be changed without damage to the proposal. The use of 
"..", ":" • and ";" is based on analogies with subranges, variable- 
declarations, and formal parameter lists respectively. Other people may 
prefer to use commas or whatever. It doesn't really matter as long as the 
abstraction is right, except for students. 



1. IMPLEMENTATION , 

I have noticed some people saying that the implementation of conformant 
arrays is unproven, and I should like to sharply disagree. There is no 
problem whatsoever about the implementation of any of these schemes, and 
they have been well-known for a very long time. The whole argument has 
been around fitting the idea into Pascal with the minimum of change to its 
fabric. Any competent implementor will be able to implement this feature 
on any machine I know, and existing implementations which differ can be 
altered very easily . 

There is one exception. Not that it is unknown, but that we know very well 
that if we are going to allow packed arrays to be actual parameters to a 
conformant array parameter, then we will be forced into either giving up 
packing completely on some machines, or imposing some ugly restrictions on 
conformant array parameters, or passing some bit-size argument and 
requiring the called procedure to reproduce the vagaries of the packing 
algorithm. The problem is essentially that the size (in bits, say) of the 
component- type may not be known until execution. For this reason, the use 
of packed in a conformant array parameter was not allowed. 



It should be realized that the inclusion of packed in the Standard means 
that all implementors must provide it (do not fall into the trap of 
thinking of the Standard as a permissive one or a layered one such as 
COBOL), and the likely effects are simply to cause it to be ignored and the 
effectiveness of the Standard nullified, or to cause no packing to take 
place when the 'Standard' compiler option is set. This would be singularly 
unfortunate for a feature whose main use seems to be to simulate something 
else (strings). It should be pointed out that its exclusion means that 
some implementors may choose to provide it as an extension. The abstract 
meaning is clear; the syntax is clear; only the implementation is 
difficult. 
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EX TRACTS FROM WORKING DRAFT 5 (Shortly to be Draft Proposal to ISO) 



Secticfn 6-6-3 



variable-parameter-specification a 

"var" identifier-list ":" 

(type-identifier i conforroant-array-schema) . 
conformant-array-schema = 

"array" "[" index-type-specification 

{ ";" index-type-specification } "]" H of" 

( type-identifier ! conformant-array-schema ) 
index-type-specification = 

bound-identifier ".." bound-identifier 

":" ordinal-typc-identifier . 
bound-identifier s identifier . 



The occurrence of an identifier within an identifier-list of a 
value-parameter-specification or a variable-parameter-specification 
shall be its defining-point as a parameter-identifier for the region 
that is the formal-parameter-list in which it occurs and its 
defir.ing-point as a variable-identifier for the region that is the 
procedure-block or function-block, if any, whose formal parameters 
are defined by that formal-parameter-list. 

The occurrence of an identifier as a bound-identifier within an 
index-type-specification shall be its defining-point as a 
bound-identifier for the region that is the formal-parameter-list in 
which it occurs and for the region that is the procedure-block or 
function-block, if any, whose formal parameters are defined by that 
foraal-parameter-list . 



If the component of a conformant-array-schema is itself -i 
conformant-array-schema, then an abbreviated form of defintiion may 
be used. In the abbreviated form, all the index-type-specifications 
shall be contained within the same enclosing square brackets, a 
single semi-colon replacing each sequence of right-square-bracket 
"of" "array" left-3quare-bracket that occurred in the full form. The 
abbreviated form shall be equivalent to the full form. 

Examples: 

array[u..v: T1] of array[j.,k: T2] of T3 
array[u..v: T1; J..k: T2] of T3 



6.6.^.3 Variable parameters. The actual-parameter (see 6.7.3 and 
6.3.2.3) corresponding to formal parameters that occur in the same 
identifier-list in the formal-pararaeter-list shall all be of the 
same type. This type shall be the same as the type of the 
type-identifier in the variable-parameter-specification if the 
formal parameter is so specified, otherwise it shall be conformable 
to the conformant-array-schema in the 
variable-parameter-specification. Bach formal parameter shall denote 
the corresponding actual-parameter during the entire activation* of 
the block. Any operation involving the formal parameter shall be 
performed immediately on the actual-parameter. 

If access to the actual -parameter involves the Indexing of an array 
and/or the selection of a field within a variant of a record and/or 
the de-referencing of a pointer and/or a reference to a 
buffer-variable, these actions shall be executed before the 
activation of the block. 

Components of variables of any type designated packed shall not be 
used as actual variable parameters. 



If T1 is an array- type, and T2 is the type the 
ordinal-type-identifier of a conformant-array-schema, then T1 is 
conformable with T2 if all the following four statements are true. 

(a) The index-type of Tl is compatible with T2. 

(b) The smallest and largest value of the index- type of Tl lie 
within the closed interval defined by values of T2. 

(c) The component-type of Tl is the same as a component-type of the 
conformant-array-schema, or is conformable to a component 
conformant-array-schema. 

(d) T1 is not designated packed. 



the smallest or largest value of the 
outside the closed interval defined by the 



It shall be an error if 
Index- type of T1 lies 
Values of T2. 

During the entire activation of the block, the first 
bound-identifier shall denote the smallest value of the index-type 
of the actual-parameters, and the second bound-identifier shall 
denote the largest value of the index-type of the 
actual-parameters. 



6.6.3.6 Parameter list congruitv . Two formal-parameter- lists shall 
be congruous if they contain the same number of parameters and if 
the parameters in corresponding positions match. Two parameters 
shall match if any of the four statements that follow is true. 

(a) They are both value parameters of the same type. 

(b) They are both variable parameters of the same type, or have 
equivalent conformant-array-schemas. Two 
conformant-array-schemas are equivalent if they have the same 
ordinal-type specified in their index-type-specifications and 
their components are either of the same type or are equivalent 
conformant-array-schemas . 

(c) They are both procedural parameters with congruous parameter 
lists, if any. 

(d) They are both functional parameters with congruous parameter 
lists, if any, and the same result-type. 



Sectio* 6'7>1 



factor a variable ! unsigned-constant ! bound-identifier 
function-designator { set-constructor { 
"(" expression ")" ! "not" factor . 
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Mr. Andy Mi eke 1 
Pascal User's Group 
University Computer Center: 
208 SE Union Street 
University of Minnesota 
Minneapolis, MN 55455 
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Dear Andy: 

Our agency sent questionnaires to about 950 members of the Pascal 
User's Group in the United States in order to gather information 
on their experience with the language and available software. Thank 
you for providing us with a copy of the User's Group mailing list 
for this endeavor. 

We are submitting the attached copy of the results of our survey to 
you for publication in the Pascal News. Also, enclosed is a copy 
of the questionnaire for your information. If you have any questions, 
please contact John McCandliss, 314-268-2786, or Sue Burklund, 314- 
268-5151. 



1 Incl 
As stated 



<*/Lv*L 



ROBERT R. RANSOM 

Director for ADP Technology 



PASCAL SURVEY 

Pascal is a computer language developed by Niklaus Wirth at ETH in 
Zurich, Switzerland. It is derived from Algol 60, but is more powerful 
and incorporates structured programming principles. Pascal has been 
implemented on a variety of computers throughout the world with the most 
common being Control Data Corporation and Digital Equipment Corporation 
computers. Its widest use to date has been as an instructional tool to 
teach students the principles of programming in a structured manner, but 
some computer companies, notably CDC and Texas Instruments are using it 
as a systems programming language. 

ALMSA developed a questionnaire which was sent to approximately 950 
members of the Pascal User's Group in the United States. We received 
about 120 usable responses, which were analyzed to provide the statistics 
for this report. The responses, especially in the area of relative speed 
and size of Pascal generated code compared to other languages, were often 
incomplete, so each area of the report indicates the number of responses 
on which it is based. 

The questionnaire brought some interesting facts about Pascal usage to 
light. The first interesting statistic is that almost \ of the responses 
were from educational institutions, and another \ were from computer 
companies. Most of the government organizations responding were research 
oriented. It is safe to say that as yet, Pascal has not moved into the 
mainstream of computer programming, although judging by the fact that 
over 4/5 of the respondents said that Pascal usage at their installation 
was increasing this development might be forthcoming in the future. 

Another interesting fact is that 3/5 of the respondents were using Standard 
Pascal. Pascal was highly rated as an educational tool, but got its 
lowest ratings as a language for writing operating systems and business 
applications. Extensions of Pascal, such as Brinch Hansen's Concurrent 
Pascal, will be necessary before Pascal will be acceptable for writing 
operating systems. Other extensions, such as better I/O capabilities 
will be necessary to make Pascal an acceptable business programming 
language. 



It is hard to make any judgment as to the efficiency of Pascal generated 
code, because of the small number of responses, and the large variety of 
compilers cited. In most cases, the Pascal generated code was both 
slower and larger compared to modules in assembly language and other high 
level languages. However, a couple of compilers, including the widely 
used University of Colorado version, were producing code that was compared 
favorably with that produced by FORTRAN compilers. 



June-October 1978 
PASCAL QUESTIONNAIRE STATISTICS 



General Statistics : Number Percent 

Number of questionnaires mailed 

Number of replies received 

Replies from organizations which didn't have working 

compilers or- said they couldn't answer our survey 
Usable replies 122 13% 



950 


100% 


155 


16% 


33 


3% 



Types of Respondents : 



a. Governmental organizations 

b. Educational organizations 
c* Business organizations 

d. Computer organizations 



Total 



10 


8.2% 


60 


49.2% 


23 


18.9% 


29 


23.8% 


122 


100.1% 



Type of Pascal Used : 

a. Standard 

b. Subset of standard 
Co Sequential Pascal 

d. Concurrent Pascal 

e. Other 



Total 



78 


65.0% 


12 


10.0% 


11 


9.2% 


5 


4.2% 


14 


11.7% 


20 


100.1% 



Note: 



These numbers are not exact since some organizations had more than 
one Pascal compiler. 



How many of these organizations use Pascal compilers 
as opposed to interpreters? 

a. Pascal compilers 

b. Pascal interpreters 

c. Both 

Total 



87 


76% 


15 


13% 


13 


11% 


115 


100% 



Percentage of coding being done at each installation in Pascal: 



a. Number of replies 

b. Average % of coding 



94 
14.5% 



Trend or Pascal usage at each installation: 

a. Replies 116 

b. Increasing 84% 

c. Decreasing or stable 16% 



June-October 1978 

Note: The following three areas were rated on a to 3 scale where- 

= Poor 

1 = Adequate 

2 = Good 

3 = Excellent 

Average 
Number of replies Rating 



Reliability of Pascal compilers: 
Suitability for the following applications: 

a. FORTRAN replacement 

b. ALGOL replacement 

c. Educational use 

d. Operating systems 

e. Systems programming 

f . Business applications 

g. Scientific applications 

Pascal's capabilities in various programming areas: 

a. I/O operations 

b. Numeric computations 

c. Integer arithmetic 

d. Character handling 

e. String handling 



116 



2.2 



110 


2.1 


95 


2.4 


104 


2.6 


88 


1.4 


101 


2.0 


87 


1.4 


99 


2.1 


114 


1.4 


122 


1.8 


111 


2.4 


114 


1.9 


112 


1.1 



Speed/size of Pascal generated code compared to a similar module on the 
same system in another language: 



Sp€ 


Jed 


Size 




a. 


Number of replies 20 


a. Number of replies 


13 


b. 


Faster 3 


b. Smaller 


1 


c. 


Slower 17 


c. Larger 


12 



Comments that many respondents made about the limitations of Pascal and 
what they thought would be the most useful extensions to Pascal: 



b. 
c. 
d. 
e. 
f. 
g. 
h. 



Formatted 1/0 

Random access capabilities 

Better interfaces with other programs 

Ability to initialize variables 

Bit strings 

Make it easier to. compile procedures separately 

More interactive functions 

Dynamic arrays 



CONVERTING AN APPLICATION PROGRAM FROM 
QMS I PASCAL 1. IF 3JJ AAEC PASCAL 8000/1.2 

Geoffrey R Grinton 

State Electricity Commission of Victoria 

Richmond, Victoria 3121, Australia 



I recently had occasion to transfer an application program originally 
written on a PDP 11/34 system using RT-11 and OMSI Pascal 1. IF to an 
installation running AAEC Pascal 8000/1.2 under MVS on a dual IBM 370. 

Although the program had originally been written with this transfer in 
mind, and hence with a minimum of system dependent features, there were 
several areas in which unexpected changes had to be made. Some of the 
changes are of a trivial nature, and were expected. Others, however, 
were less obvious, and posed some problems. 

This note describes the differences encountered, and is intended to show 
others the sorts of problems likely to be encountered in such an 
exercise. 

1. The original version was written using a mixture of upper and lower 
case characters. When this was fed into the AAEC compiler the compiler 
crashed; no indication of the likely cause of the problem was given, so 
a bit of inspired guess-work was required. The solution used was to 
change the whole program to upper case. 

2. It was necessary to convert occurences of the characters C, 3 and 

to the AAEC equivalents, namely (., .) and @. I have since found that 
the AAEC compiler accepts C and 3, but this is not documented. 

3. There were several occurences of VALUE as a variable name. Since 
the AAEC compiler allows a VALUE segment, which follows immediately 
after the VAR segment, this caused it some confusion. 



files, including INPUT 
is optional in the OMSI 



4. I had omitted to include names of external 
and OUTPUT, in the program header (which 
compiler), so these had to be inserted. 

5. It was necessary to reduce the nesting level of procedures, since 
AAEC allow only six levels. The OMSI compiler allows up to ten levels. 
Such a restriction would appear to me to be contrary to the philosophy 
of structured programming, as it requires the programmer to either use 
larger (and hence less comprehensible) blocks, or to place procedures 
which should logically be contained in another block at a higher level. 

6. The OMSI system had failed to detect an invalid assignment to a 
subrange variable. This was correctly diagnosed by the AAEC run-time 
system. The particular example was a subtle form of: 

y a r index :1.. top; 

index : = 0; 

7. The AAEC system, when running under the Time Sharing Option (TSO) of 



MVS does not actually write to a terminal until a line is completed, ,—' 
with writeln. Hence all prompting messages had to be changed to 'use ^. 
writeln instead of write. m 

GO 

8. It was necessary to change all output formats to allow for a ^ 
carriage control character. This was not strictly necessary, but it was »— • 
required if the system default DCB information was to be used (ie "^ 
RECFM-FA). 

9. Since the AAEC version does not specifically allow for interactive 
use, all input had to be changed so that the file pointer was always 
defined. This was done primarily by changing all occurences of 
readln(. . ) to readln; read(. . ), although several other minor programming 
changes were also necessary. 

10. The OMSI compiler does not pre-declare files INPUT and OUTPUT, and 
consequently does not allow references to input*- to look-ahead on the 
input file. With the changes described in point 9, it was useful to be 
able to do this in the AAEC verion of the program. Further changes 
became necessary, however, when I realised that the system was adding 
extra blanks to the ends of my input lines, to fill them out to 80 
characters. (I can't say that I wasn't warned by Jensen and Wirth, but 
that one took a lot of finding!) 

11. OMSI Pascal uses modified forms of reset and rewrite to attach 
actual RT-11 files to internal file variables. The AAEC system requires __. 
this connection to be made externally, and hence the appropriate 3> 
initialisation routine had to be changed. o 

12. As OMSI Pascal ignores the 'packed' attribute, and automatically 
packs all character arrays and strings, I had not specified arrays of |^> 
type char as packed. This was necessary on the AAEC system for proper g 
operation of my program. 

The conversion process was, despite the differences outlined above, 
probably simpler than I had expected. Apart from the I/O related 
difficulties, there were few incompatibilities between the systems, and 
conversion of the whole program of 1200 lines was completed within a 
couple of days. 



15th May, 1979 
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DOES SCOPE = BLOCK IN PASCAL? 

T. P. Baker* 

Department of Computer Science 

The University of Iowa 

Iowa City, Iowa 522^2 

and 

A. C. Fleck 

Department of Computer Science 

and 

Weeg Computing Center 

The University of Iowa 

Iowa City, Iowa 522*i2 



INTRODUCTION 

There seems to have developed some controversy over whether the scopes of identi- 
fiers are (or should he) synonymous with blocks in PASCAL. In this note we call 
attention to the formal statement of the "rules" dealing with this situation, point 
out several other items in the literature that address the question of the title, and 
present our own personal conclusions. We relate our comments first with respect to 
"Standard" PASCAL and then to the new BSI/ISO Working Draft Standard PASCAL. 

WIRTH'S STANDARD PASCAL 

There are several levels of documentation to consider in this case, in decreasing 
order of abstraction: the Report [2], the User Manual [2], and the several E.T.H. 
compilers. Arthur Sale in [3] argues strongly the position that scope = block. But 
we would like to suggest that there are loopholes. The Report is unfortunately vague. 
In section 10, we are told that scope = procedure (or function) declaration and that 
identifiers are not known outside their scope. But it gives no details of how they 
are known inside their scope. The crucial issue is nested scopes which are mentioned 
in Section 2 but for which no rules are given. Section k of the Report tells us that 
the association of an identifier must be unique within its scope. This is essentially 
the extent of the specifications in the Report. In this light, consider the following 
example : 

1 PROGRAM PI (OUTPUT); 

2 PROCEDURE Q; BEGIN WRITELN(l) END; 

3 PROCEDURE R; 

1+ PROCEDURE S; BEGIN Q END; 

5 PROCEDURE Q; BEGIN WRITELN(2) END; 

6 BEGIN S END; 
T BEGIN R END. 

Now there are two definitions provided for identifier 'Q' within nested scopes. 
The one within R must not be known outside R. There is only one invoking instance 
of the identifier 'Q' (hence its association must be unique) and its occurrence is 
validly within both scopes and the Report's rules give us no reason for preference. 



*Present address: Mathematics Department, Florida State Univ., Tallahassee, FL 32306 



Next we consider the User Manual. Here in Chapter 1 (pp. 6-7) we find it again 
stated that scope = procedure declaration. Also it is stated "the scope or range of 
validity of an identifier x is the entire block in which x is defined, including 
those blocks defined in the same block as x," Applied to program PI above, this 
would seem to imply that the correct output of PI is 1. However the above quote has a 
parenthetical comment that all identifiers must be distinct for this to apply and 
refers to Section 3.E for the case where identifiers are not necessarily distinct 
(this is the case with Pi). Reading Section 3.E, we find that the definition of a 
variable definition in an inner block is valid throughout that block. This might sug- 
gest the correct output of PI is 2. Actually this rule has nothing to do with program 
PI as it deals exclusively with variable identifiers, the topic of Section 3.E. 
Unfortunately the other sections on type identifiers, procedure identifiers and con- 
stant identifiers give no rules at all. 

The last, most specific and least satisfactory source for a resolution of scope 
rules (other than for variable identifiers) is the E.T.H. compilers. Because of 
Wirth's close association here, their performance must be considered significant. The 
output of both the Version 2 and Version 3 compiler for PI is 1. This performance is 
supported by the rule in Chapter 1 (p. 8, item l6) of the User Manual that "All ob- 
jects must be declared before they are referenced" (two exceptions noted are pointer 
types and forward procedures). In the absence of other rules about scope it is not 
unnatural to apply this one, hence accepting the outer definition throughout its scope 
until another occurs (the Version 2 and 3 compilers do violate the unique association 
rule which does not come up in Pi). This is presumably the reason for Watt's [k] 
assumption that Sale [3] criticizes. 

THE BSI/ISO STANDARD 

We now turn our attention to the new Draft Standard [l] . While there are prob- 
lems with the existing language specification, it is this new definition which causes 
us the most serious concern. The Draft Standard eliminates the previously existing 
omissions on the specification of scope rules. There is an explicit enumeration of 
the nested scope rules for all varieties of identifiers (see Section 6.2.1). Unfor- 
tunately, as we shall see, these rules imply that scope 4- block for all cases except 
variable and type identifiers. 



Each identifier has a defining occurrence and each defining occurrence has a 
scope which encloses all "corresponding occurrences" (a term not defined). Here the 
Draft Standard leaves some ambiguity as it does not state precisely where such scope 
begins and ends. Since the scope must enclose all "corresponding occurrences" we 
shall simply assume that the scope ends with the end of the block in whose heading the 
defining occurrence appears. The choice for the beginning of the scope is another 
question. Since each defining occurrence is prescribed as having a scope associated 
with it (i.e., scopes are associated with defining occurrences not blocks), one seems 
naturally forced to assume that such a scope begins with the defining occurrence. 
This assumption seems reinforced by the rule (in Section 6.k) that the scope of the 
defining occurrence of a type identifier does not include its own definition, except 
for pointer types. There is one exception to this assumption explicitly stated in 
rule (5) of Section 6.2.1. This rule states that the defining occurrence of any 
identifier or label must precede all its "corresponding occurrences" except for a 
pointer-type identifier which may have its defining occurrence anywhere in the type- 
definition part. Hence we assume that the scope of a pointer-type identifier begins 
with the beginning of the type-definition part rather than with its defining occur- 
rence , 



Now consider the previously given program example PI. There is no longer any 
doubt over what its correct output must be. This program has two defining occurrences 
of the identifier 'Q' (the specification of a defining occurrence for a procedure 
identifier is given in Section 6.6.1), in lines 2 and 5. The scope of the first 
extends to the end of PI (i.e., lines 2-7 ) and the nested scope of the second extends 
to the end of procedure R (i.e., lines 5-6). Clearly then the call in line 1+ is a 
"corresponding occurrence" for the definition in line 2, an association clearly vio- 
lating ALG0L60- style scope rules. 

The same situation prevails for constant identifiers. As an example consider 

1 PROGRAM P2( OUTPUT); 

2 CONST TWO = 2; 

3 PROCEDURE Q; 

k CONST ONE = TWO; 

5 TWO = 1; 

6 BEGIN WRITELN(ONE) END; 

7 BEGIN Q END. 

We do not include the scope analysis for this program as it is similar to that 
for program PI. The upshot is the same as for procedure identifiers, namely scope i- 
block for constant identifiers. 

On the other hand since type-identifiers cannot occur in a heading prior to the 
type-definition part, rule (5) of Section 6.2.1 implies that scope = block for type 
identifiers. For instance, in contrast to the previous examples, the program 

1 PROGRAM P3 ( OUTPUT ) ; 

2 TYPE A = RECORD L : tA; C : REAL END; 

3 PROCEDURE Q; 
k TYPE B = tA; 

5 A = RECORD L : B; C : INTEGER END; 

6 VAR X : B ; 

7 BEGIN NEW(X); Xt.C :=0.5 END; 

8 BEGIN Q END.- 

is illegal because of the type conflict in the assignment in line 7 (however the Ver- 
sion 3 E.T.H. compiler finds it legal). 

Also since variable identifiers cannot be used in the heading at all, these rules 
imply that scope = block for variable identifiers as well. Hence for the Draft Stan- 
dard we get two answers to the question of the title; 'yes' for variable and type 
identifiers and 'no' for constant, procedure and enumeration-type identifiers. 

CONCLUSIONS 

The lack of specification of rules for nested scopes in the original PASCAL defi- 
nition has resulted in different interpretations being taken by different implementa- 
tions. This point has already been made in [5], The fact that so basic an issue must 
be settled has been recognized in the development of a draft standard. 



We feel that while the Draft Standard does resolve the ambiguities of scopes , the 
solution that is proposed is very poorly conceived. The answer to the question "does 
scope = block?" should be uniform for all varieties of identifiers and furthermore we 
agree with Sale [3], that uniform answer should be yes. 



Programs PI and P2 show how present scope rules provide for the binding of cor- <— > 

responding occurrences of identifiers to defining occurrences outside the block of the ^ 
corresponding occurrence even though this block itself contains a defining occurrence. 

A convention which provides for the binding of one identifier to two definitions with- m 

in the same block seems entirely contrary to the evolution of PASCAL. ^ 

The scope rules should state that the scope of a defining occurrence extends from i—^ 
the beginning of the block in whose heading it occurs to the end of this block. This "^ 
would replace rules (l) and (2) of Section 6.2.1 of [l]. The other rules would be 
retained as stated; however we would rephrase rule (5) slightly to say that the com- 
pletion of the definition for a defining occurrence must precede all corresponding 
occurrences — then the scope rule in Section 6.k is dropped. This would make programs 
PI and P2 illegal as they then violate rule (5) — the defining occurrence in the nested 
block does not precede first use. It has already been suggested [5] how this inter- 
pretation can be handled in a one-pass compiler. The only complication to this comes 
in the exception to rule (5) for pointer-types which must force the binding of all 
such identifiers (even those with definitions in enclosing scopes) to be deferred 
until the end of the type-definition part . 

We feel the approach we suggest provides a conceptually cleaner solution to the 
scoping questions. The treatment of all varieties of identifiers is internally con- 
sistent and consistent with the conventions of other block structure languages as 
well. Moreover it conforms with the principle of locality. With the rules given in 
the present Draft Standard, a block can contain identifiers with both a local and a 
nonlocal binding — a very confusing situation. 
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A NOTE ON PASCAL SCOPES 
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In response to. the recent efforts toward development of a PASCAL standard [l], we 
would like to point out a peculiarity we have observed in the PASCAL notion of scopes, 
as exemplified in the E.T.H. compilers, and to suggest how a "cleaner" alternative 
notion might "be implemented. 

Beginning with ALG0L60 , "block structured" languages have followed the convention 
that scopes of local declarations correspond to the boundaries of the blocks in which 
they occur. Since PASCAL superficially appears to follow this convention, a programmer 
is likely to go along for some time before he stumbles upon a case where PASCAL scopes 
do not correspond to block boundaries. When he does, it is likely to be a source of 
confusion. For example, consider the programs and output below (from Version 3 of the 
PASCAL 6000 compiler): 

1 PROGRAM PI (OUTPUT); 

2 PROCEDURE Q; BEGIN WRITELN(l) END; 

3 PROCEDURE R; 

U PROCEDURE S; BEGIN Q END; 

5 PROCEDURE Q; BEGIN WRITELN(2) END; 

6 BEGIN S; Q END; 
T BEGIN R END. 

1 
2 

1 PROGRAM P2( OUTPUT); 

2 TYPE A = CHAR; 

3 PROCEDURE Q; 
k TYPE B = "A; 

5 A =' RECORD L,R: B END; 

6 VAR X: B; 

T BEGIN NEW(X); X* := 'A ! END; 
8 BEGIN Q END. 

1 PROGRAM P 3 ( OUTPUT ) ; 

2 VAR F: INTEGER; 

3 PROCEDURE Q; 

k PROCEDURE R; BEGIN WRITELN(F) END; 

5 FUNCTION F: INTEGER; BEGIN F := 2 END; 

6 BEGIN R; WRITELN(F) END; 
T BEGIN F := 1; Q END. 



Note that according to . current and proposed scope rules [l] , this is the "correct" 
program behavior in each case. 

We propose that PASCAL can be standardized to follow the ALGOL60 scope conventions, 
with the added restriction that (except in recursive pointer type declarations) no use 
of an identifier may precede its declaration (this appears to be the approach taken in 
ADA [2]). Thus, program PI above would be considered incorrect, since the use of Q in 
procedure S precedes a local definition of Q. P3 would be incorrect for a similar rea- 
son, because the use of F in procedure R precedes a local declaration of F. Program P2 
would be considered incorrect, but for a different reason. The variable X would be in- 
terpreted as a pointer to a record, so that the assignment "X" := 'A'" would be a type 
conflict. This is exactly what would have happened if the outer declaration "A = CHAR" 
had not been present. In this case, the convention followed by the compiler not only 
makes the interpretation of the procedure Q dependent in an unobvious way on its global 
environment , but also effectively blocks the possibility of defining a pointer type for 
the local record type A. 

A single pass compiler can enforce these conventions. On first encountering a use 
of an identifier X that is not yet declared in the local block, the compiler attempts 
to resolve the reference to a previously processed nonlocal declaration, say D, in one 
of the surrounding blocks. If this search is successful, the processor creates new 
"dummy" entries for X in the symbol table for the local block and all surrounding blocks, 
out to the block where D appeared. These dummy entries will include a pointer to the 
entry corresponding to D and will serve the purpose of insuring that any subsequent dec- 
laration of X locally will be deleted and treated as an error. 

PASCAL already provides means for handling the few cases where forward references 
are unavoidable. For procedures, functions, and labels, there are forward declarations. 
For recursively defined pointer types, processing can be deferred until it can be 
determined whether a type identifier should be resolved as a local or nonlocal refer- 
ence. For example, processing of "B = *A" in P2 would be deferred until the local dec- 
laration of A was encountered (or until the end of the TYPE section). 

We believe that the proposed conventions are an improvement in the direction of 
simplicity and conformity to established practice. Furthermore, as exemplified best in^ 
program P2, they improve program modularity, by permitting reliable local resolution of 
references, which under present rules is impossible. 



[l] A.M. Addyman et al. "A draft description of PASCAL," Software Pract. & Exper . 
9, 5(1979), 38l-^2H; also PASCAL News lU(l979), 7-5 1 *. 

[2] Preliminary ADA Reference Manual, SIGPLAN Notices Ik , 6(1979). 
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One of the strongest features of Pascal is the ability to define new data 
types. Because this ability is central to the language it is unfortunate that the 
original documents defining Pascal (i.e., the Jensen and Wirth "User Manual and 
Report" and the axiomatic definition) did not precisely state when two variables or 
values are of the same type, or precisely what constitutes "type checking" in an 
assignment statement or procedure call. Language designers have exercised their 
skill and imagination in attempting to resolve the ambiguities without unduly 
disturbing the "spirit of Pascal"; this note is one such attempt. 

Recently, the BSI/ISO Working Draft of Standard Pascal was published in Pascal 
News #14, and this standard exhibits a particular (and carefully considered) solution 
to the type equivalence problem. The technique is a hybrid of name and structural 
equivalence; for strings and sets, the standard specifies a structural definition of 
type equivalence (for a discussion of name versus structural equivalence, see Welsh, 
Sneeringer and Hoare, "Ambiguities and insecurities in Pascal", Software Practice and 
Experience, N 7, 1977). While the solution is relatively direct it leaves a great 
deal to be desired, for instance, under the proposed interpretation all variables 
which are structurally integer or subrange of integer are of compatible types. Since 
the criterion for type equivalence is a function of the underlying structure, 
seemingly inconsistent cases arise. After the program fragment 



VAR 



: PACKED ARRAY 
: PACKED ARRAY 
: PACKED ARRAY 
•.PACKED ARRAY 



[1..10] OF integer; 

[1..10] OF integer; 

[1..10] OF char; 

[1..10] OF char; 



the assignment "u:=v" is legal whereas "x:=y" is not. (The first must be permitted 
to include statements like "ur^'abcdefghij '", and the second is presumably denied to 
limit the complexity of the equivalence definition and forthcoming Standard Pascal 
compilers. ) 

The rest of this note describes, a different role for types and type equivalence 
in a Pascal-like language. The scope of the solution is strictly limited because 
significant extensions to the syntax of Pascal were not considered (this eliminated 
interesting but grandiose schemes involving a new unit of program modularity, as well 
as the possibility of explicit type transfer operators). The details are developed 
from a series of principles embodying my understanding of what strong typing means in 
the context of Pascal. 



PI. Every variable has a unique type and a unique symbolic type 
name. 

Since both the type and type name are unique, the type of a variable can be referred 
to by its symbolic name without ambiguity. In the interests of simplicity it seems 



wise to prohibit multiple names for the same type. Types are assigned to variables 
rather than values, because I wish to allow distinct types to exist with the same 
value set. 



P2. All types are either predefined or created in a TYPE definition 
part. 

The only function of the TYPE part is to define new types; the only function of the 
VAR part is to define new variables. As obvious as this may appear at first glance 
it is a very strong restriction — it implies that all types must be explicitly named 
in a TYPE part. For example, the Standard Pascal fragment 



VAR 



:ARRAY [1..100] OF REAL; 
: (red, blue, green) ; 



would have to be rewritten in order to conform to principle P2 



TYPE 



vector 
color 



ARRAY [1..100] OF REAL; 
(red, blue, green) ; 



: vector ; 
: color; 



This principle will force the creation of many new names in a typical program, one 
for each type, but at the same time it provides the basis for a simple and explicit 
test for type equivalence. In fact, the spread of names can be controlled in a 
manner described below. 



Every clause in a TYPE definition part (i.e., every use of the 



P3. 

operator "=") creates a unique type. 

This principle, too, seems like good common sense: the TYPE part exists to define 
new types. (It is interesting to note that the proposed Standard Pascal allows new 
types to be created in a VAR part, and doesn't require types to be created by a TYPE 
part!) 

P4. Two variables have the same type if and only if they are 
declared with the same type name. 

In other words we adhere to a very strict form of name equivalence. After the TYPE 
and VAR parts 



TYPE 



speed = -real; 
weight = real; 



a,b 
x 

y 



: speed; 
: weight; 
: weight; 
:real; 



the variables a and b have the same type (namely speed) ; x and y have the same type 
(weight) and no other type equivalences exist. 



3> 
CD 

m 



P5. In every assignment, the type of the variable on the left must 
be the same as the type of the expression on the right (exception: 
integers may be assigned to real variables). 

I believe this is the simplest definition of "strong typing". To continue the 
previous example "a:=b" is a legal assignment but "a:=x" is not, even though the 
values of both a and x are real numbers. Since parameter transmission can be 
described in terms of assignment this principle applies to parameters in function and 
procedure calls; it forces an exact match between the types of formal and actual 
parameters, and it implies a careful interpretation of operator overloading in 
expressions (discussed after P 7 below). 

The exception is galling but historically founded. It is pervasive, as will be 
seen, because it implies that any type derived from integer is assignment compatible 
with any type derived from real. 

P6. The types of all constants (simple and structured) are 
determined from context. 

There is no way to avoid this, given P5 and the fact that variables of different 
types may have the same value set. Continuing the example, if the statement "a: =4. 7" 
is legal, then by principle P5 the constant "4.7" is of type speed; but if "x:=4.7" 
is also legal, in this case the same value has type weight. To reconcile these 
cases, the type of a constant must be permitted to be a function of its context. 
(Note that P6 paves the way for the introduction of other types of structured 
constants, e.g., record and array constants; the proposed BSI type equivalence 
definition does not extend so easily.) 

P7. A created type inherits all of the predefined operators on its 
underlying type, but none of the user defined functions or 
procedures. 

This principle is admittedly a compromise. Since the ground rules forbid syntactic 
extensions, the promotion of operators to the new type must be automatic, and the 
only issue remaining is which operators should be promoted. A primal set of 
operators is specified in Standard Pascal; this provides a natural partitioning. (If 
user defined functions and procedures were promoted as well, ambiguities would result 
which could only be resolved through explicit typing of constants.) 

An operator in the language (e.g., +) consists of a semantic action (e.g., 
addition) and a "signature", a template giving the types of the arguments and result 
of the operator (e.g., integer + integer -> integer). A user-defined type extends 
the set of operators available to a program, implicitly creating new operators from 
old ones by combining the old semantics with new signatures; each new signature is 
obtained from an old one by uniformly substituting the new type name for all 
occurrences of the base type in the old signature. For example, all programs will 
initially possess an operator + defined by 

+ = addition; real + real -> real 

and in a program containing the declarations of speed and weight above the operators 



addition; speed + speed -> speed 
addition; weight + weight -> weight 



are also available; but it would be impossible to add a "speed" to a "weight" or a 



"real". 

With some information about context, these principles are sufficient to deduce 
the type of an expression or subexpression, or to select the correct operator for an 
overloaded operator symbol. Given 

IF 3 < round(x/4.5 + 3.0) THEN... 

the operators in the boolean expression must be 



< == less than 

round 

+ == addition 

/ -«- divide 



integer < integer -> boolean 
weight -> integer 
weight + weight -> weight 
weight / weight -> weight 



and the constants 4.5 and 3.0 must both be of type weight. In a few cases involving 
only constants, it may not be possible to determine the constituent types, but the 
correct action is obvious, e.g., 

IF 3 IN {1,5,7,12} THEN... 

does not permit the determination of a unique type either for the set or the base 
type of the set elements, but the value of the expression must be false in spite of 
that. 

P8. A subrange is a global constraint on the set of values assumed 
by a variable; it does not create a new type. 

Subranges are used for many different purposes; sometimes it would be useful for them 
to be distinct types and sometimes not. For this reason it is a good idea to 
accomodate both usages — if there is a simple way to do so. At this point I admit to 
bending the rules, and introduce one minor change to the Pascal syntax, in the form 
of a typed subrange. A declaration of a variable 

i : integer 1..10 

means that the type of i is integer, but its values are constrained to the closed 
interval 1..10. A typed subrange consists of a type name followed by a subrange 
contained in the value set of the type. If the type name is omitted, it is assumed 
to be Integer. If a typed subrange appears in a variable declaration, the variables 
have the named type; but if the typed subrange appears in the TYPE section, it 
participates in the creation of a (range restricted) new type, just as required by 
P3. For example 






TYPE 



VAR 



i 

am 
pm 
h 



= I. .24; 

: integer; 
:hour 1..12; 
:hour 13.. 24; 
:hour; 



The variables am, pm and h are all of type hour, and the assignments "h:-am" and 
"h:-pm" will always be valid; "am:=pm" will never be valid because the value sets of 
am and pm are disjoint; "am:=i", "pm:=i" and "h:=i" are all prohibited by type 
mismatch. 



These principles lead to a view of types very different from the BSI/ISO 
Working Draft. It is a much more restrictive world, emphasizing type safety at the 
expense of flexibility. I suspect that neither approach is clearly superior for 
"general purpose" use, but the reader can form his own opinion. 

Finally, a suggestion for controlling name proliferation appeared in an 
entertaining paper by Robert G. Herriot, "Towards the ideal programming language" 
(SIGPLAN Notices, V 12 N 3, March 1977). Herriot proposed the use of English 
articles ("the", "a", "an", etc.) and adjectives to create variable names. With this 
syntactic mechanism, the fragment 

TYPE 

car = (f ord,GM, Volkswagen) ; 
VAR 

a car :car; 

a sports car :car; 

a compact car :car; 

a blue electric car rear; 

would declare four enumeration variables, referred to in the program text as "the 
car", Vthe sports car", "the compact car" anJ "the blue electric car". Thus names 
for variables can be directly manufactured from type names, frequently improving the 
program's readability. 



□ □ □ □□ □ □ □ 



***************** 

FIXING PASCAL'S I/O by Richard J. Cichelli 

There have been a flurry of articles advocating modifications to Pascal's 
file facility to improve its functionality for input/output. Here, questions 
regarding terminal I/O and relative record I/O will be discussed. 

Many criticisms of Pascal's file facility contain arguments that Pascal's 
files don't support the full data set manipulation capabilities of the host's 
operating system. An alternate view of the situation is to ask if the problem 
to be solved can have its solution cleanly specified as an algorithm in Pascal. 
If so, request that the Pascal compiler/ system writer provide an implementation 
complete enough to run the program efficiently. In short, buy compilers and 
computing systems to run your programs rather than write programs to instruct 
your (particular) computer. 

Wirth created Pascal files. In the Revised Report Section 2, paragraph 10, 
Wirth defines them as sequences of components of the same type. Although an 
implementer may map Pascal files into sequential data sets, this isn't required 
by the definition. The Report doesn't seem to require that the ideas of I/O 
and files be associated. A valid Pascal implementation could exist on a system 
which lacks backing storage and a third generation file system. If this is the 
case for your system and you still can run your Pascal programs, what do you 
care? Besides, future data base oriented systems may avoid the redundancy of 
a "file system". The problems of named data sets and directories are obviously 
best dealt with in terms of local predefined (not standard) procedures. 

For legible input and output (Report section 12) Pascal has a special type 
of file called a text file. Text files have a special substructure and special 
procedures and functions. Since sequences work and Pascal has appropriate fa- 
cilities for manipulating them (i.e. the Pascal file primitives), it would be 
very strange if you couldn't make Pascal talk to terminals. Wirth specifically 
mentions them in the first paragraph of section 12 and, guess what, many imple- 
mentors have succeeded in implementing exactly what the report calls for and 
having facile terminal interaction as well. One of the techniques is called 
"lazy I/O" and it is fully detailed in Pascal News #13. 

There are those who want to put random I/O or "direct access files" into 
Pascal. What's Pascal missing? Surely not random access. In the Report sec- 
tion 2, paragraph 6, the array is discussed and specifically called c. random 
access structure. "But", you say, "I can't fit big direct access files in 
core". Every implementation of Pascal is likely to have some restrictions. 
Perhaps an array will need to be stored on bulk storage. Would you embed this 
limitation in the language and in your algorithms and programs? If you need 
to worry about a hierarchy of memory access facilities in these days of virtual 
memory, etc, then a pragma or compiler directive might be the appropriate mech- 
anism for suggesting to a particular compiler that certain data be placed on 
backing store. Note: There is no prohibition to passing arrays (e.g. an im- 
plementation relative records I/O) as program parameters. See the Report sec- 
tion 13. Program parameters can reference any external object." It is only 
suggested that these are "(usually files)". Thus arrays and pointer based 
data structures can be external objects to Pascal programs. (The "(usually 
files)" reference has been removed from the current draft standard document.) 

Although doing relative record I/O with Pascal arrays may seem strange at 
first, adding the unnecessary notion of memory hierarchies to the language is 
far worse. The IBM System/38 has a uniform 48 bit addressing mechanism. A 
System/38 applications programmer does quite well while being unaware of the 
storage location of his data whether it be cache, core, disk buffer or on disk. 
If the 38 can be said to auger the future, then certainly Pascal shouldn't take 
a step backwards and introduce concepts which provide no additional functionality: 

In summary, fixing Pascal's I/O only requires implementing what the Report j 
suggests. 

***************** 
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Simpascal 



Introduction 

This article presents a new extension (called Simpascal) to Pascal. The goal of this 
extension was to provide facilities for simulating discrete time systems in the way similar to 
the one adopted in Simula. This goal has been achieved with no changes in the original 
Pascal compilers, but rather by use of some run-time routines. Simpascal has been 
implemented on CDC Cyber73 and IBM 360. 



Background 

Simpascal was designed as a part of the OSKit Project (simulation of operating systems 
[1]) at the Institute of Informatics, University of Warsaw. Those extensions were necessary 
since existing standard Pascal facilities didn't allow one to write a simulator in this language. 
The reason for creating a new tool instead of using Simula was mainly better performance of 
the Pascal object code. Besides, all other parts of the project (data input preparation and 
output analysis) had been already written in Pascal. 

A general design of Simpascal and its implementation on the Cyber73 were made by 
Jarek Deminet, while some improvements and the 360 version were prepared by Joanna 
Wisniewska. A standard Pascal compiler was used on the Cyber/3. 360 compiler was 
produced at the Institute of Computer Science, Polish Academy of Science. The whole work 
lasted approximately 6 weeks. 



Description 



A simulator in Pascal (as in Simula) consists of some number of coroutines, each of 
which implements one process. At any given time one of them is active and the others are 
suspended. Some of the latter may be ready to run and wait in a so-called Sequential Set 
(SQS), other are blocked. SQS is ordered according to increasing time, which is an attribute 
of each process. Full description of this idea may be found in [2]. From this point on, a term 
routine will mean either a coroutine, subroutine or the main program, while a subroutine will 
be either a procedure or a function. 

In order to provide all expected functions the following subroutines were implemented: 



function Create (procedure P) : coroutinelD; 

Creates a new process (coroutine), with the same attributes and the body as in the 
procedure given as a parameter. This coroutine is started; after an initial part it 
should call Detach (see below). Control then returns to a creator, and the function 
returns as its value a unique coroutine identifier. The first routine calling this 
function is called a root of the whole set of coroutines. There is a restriction that 
Create may be later called either by the root or by any other coroutine, but not in 
its initial part {i.e. no nesting of Create calls is allowed). 

procedure Detach; 

Finishes an initial part of a coroutine 



and returns control to its creator. 



but also removes the current coroutine from 



If that was the current coroutine, the next 



procedure Start (C: coroutinelD; max time: real ) ; 

Starts the coroutine C, thus initiating the whole simulation. It should be pointed that, 
unlike in Simula, an root is not a coroutine itself and may be resumed only after 
finishing the simulation. Simulation ends as soon as there is no process in the SQS 
with its time less then the max time parameter of Start. 
This routine may be called only by the root. 

procedure Activate (C : coroutinelD; delay: real); 

Makes the coroutine C ready, i.e. inserts it into the SQS. Its time will be equal to the 
time of the currently active (current) coroutine increased by delay. If delay is 
negative, then the coroutine C will be resumed immediately (becoming active), and 
the current coroutine will be suspended. 

procedure Pass (C :coroutineID) ; 
Acts similarity to Activate (C.-l) 
the SQS. 

procedure Cancel (C :corout inelD) ; 
Removes the coroutine C from the SQS. 
coroutine from the SQS is resumed. 

function Time (C : coroutinelD) : real ; 
Returns time of the coroutine C. 

procedure Hold ( increment : real ) ; 

Suspends the current coroutine, increases its time by increment and resumes the 
first coroutine from the SQS. 

function This : coroutinelD; 

Returns an ID of the current coroutine. 

There is one very unpleasant and artificial restriction for a call of the so-called special 
routines, which may change an active coroutine (i.e. Activate, Pass, Cancel and Hold). If 
any of those subroutines is called from a Simpascal subroutine, called in turn (directly or 
indirectly) from a coroutine, then all subroutines down to the level of the coroutine will be 
immediately terminated. That means that the coroutine is suspended and reactivated always 
at its own level. This concept was called husking and is necessary to ensure stack 
consistency. 



Implementation 



The data structure on which Simpascal subroutines operate is very similar in both 
implementations so it will be presented here in a relatively machine independent form. 



Each instantiation of every Pascal routine is defined by a segment on the stack (the 
routine is called an owner of this segment). Each such segment (except the first one, 
corresponding to the main program) consists generally of two parts: 

Environment definition 

Contains all information necessary to refer non-local objects, to safely execute a 
return jump, and to perform an error handling action if necessary. 

Local delta 

Contains local variables (which include also parameters of the call, compiler- 
generated auxiliary variables and space for registers saved in case of further routine 
calls). Generally, this part is of no interest for Simpascal, except for register Sciving 
space. 

A base (an address of the first word) of the segment of the current routine is pointed by 
one of the registers (a B register on CDC, a general purpose register on IBM), which will be 
called a Base Register (BReg). Also the first free location above a top of the stack is pointed 
by a register (Top Register or TReg). 

In case of ordinary Pascal subroutines information in the environment definition is as 
follows: 

Static Link (SLink) 

Points to a base of the segment defining the latest instantiation of the routine in 
which the segment's owner was declared. A chain of those links defines an access 
path to all non-local objects. 
This link is created always by the caller, according to its own access path. 

Dynamic Link (DLink) 

Points to a base of the previous segment on the stack, i.e. the segment 
corresponding to the routine which called the owner of this segment. It is used to 
restore the BReg before return and to produce a Post-Mortem Dump should an 
error arrive. 
This link is created by the routine itself using the old value of BReg. 

Return Address (RAddr) 

Contains the address to which control shuld be transferred in a return jump. 
This address is provided by a caller (passed through a register). 

Figure 1 presents the general structure of the Pascal stack. 

The same data structure had to be adopted in Simpascal, since the code of coroutines 
was to be the same as for normal subroutines. Several assumptions had to be made, 
however, to ensure a consistency of the structure: 

All coroutine segments occupy a contiguous space on the stack, directly above the 
segment defining the root of the system (there may be no other segments in 
between). 

The stack of only one coroutine at any particular time (the active, or current coroutine) 
may consist of more than one segment. This would mean that no action which 
implies a change of the active coroutine may be undertaken from any level other 
than the level of the coroutine itself. To allow creating of user-defined control 
transfer subroutines the concept of husking (described above) was adopted. Its 
implementation is very simple: any special subroutine removes from the stack all 
segments from above the block of the coroutine segments. 
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Figure 1. Pascal stack structure. 
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Figure 2. Simpascal stack (only some parts shown) 



The segment for each coroutine was changed in a manner invisible to ordinary routine 
code. First, a negative purt was added. It contains a restart addiess for an inactive coroutine, 
and also some additional information (time, status and some pointers) used by routines 
which handle and sequence processes. The meaning of some standard fieids was also 
modified. Since the assumption is that a coroutine will never execute a return jump (because 
it would destroy the stack structure), RAddr points to an error-handling routine. 

DLink, in turn, no longer points to the previous segment on the slack, since it is not 
intended to be used to update the BReg. Because of some functions played by DLink during 
standard en or handling, it was decided that this it should point to a base of the root's 
segment. 

Contents of BReg, TReg and SLink were left unchanged. 

Figure 2 illustrates the general stack structure in Simpascal. 

! f 1 order to have such a structure, the following actions have to be performed by Create 
before catling a coroutine: 

- setting BReg to a base of the root; 

- incrementing TReg by the size of the negative part of the segment; 

- setting SLing according to information which is always a part of the actual- parameter- 

descriptor in a call-by-procedure in Pascal. 



Results 

Several programs have already been written in Simpascal and run on both machines, 
fulfilling all expectations. A comparison with Simula shows that a program in Simpascal 
needs 50 to 80% less memory and 50 to 70% less time. This is mainly due to much simpler 
memory structure allowing better performance of the code. 
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Some observations on Pascal and personal style 
Arthur Sale 
Tasmania, 1979 June 



Background 

Recently, arising out of a course I gave for microprocessor engineers and 
their possible use of Pascal, I had to write a program of around 800 lines 
to control a hot-plate assembly (as might be installed in a home with 
provision for switching the hot-plates individually up or down at selected 
times) . The purpose of the program was to demonstrate the viability (and 
superiority!) of Pascal for microprocessor purposes over assembly code or 
Fortran. The experiment was a demonstrable success, taking one man-day to 
write together with its correctness proof, and another man-day to transform 
the abstract program into one having some useful properties for micro- 
processor Pascal compilers and run-time support. The experiment will be 
reported elsewhere; by contrast the writing of the consequent paper has 
consumed over a man -week, and nearer two... 

However, in the course of writing this up, I came across some interesting 
facts I should like to share with the readers of Pascal News. They relate 
to personal stylist ics, and use of Pascal's features. None of the reported 
statistics here were considered specifically while writing the program: 
they reflect a personal style. 



Identifiers 

The program contains 120 identifiers, and one label (as a consequence of a 
transformation to eliminate a task). The length distribution of the 
identifiers is shown in Figure 1. 




It is interesting to note that approximately 55% exceed 8 characters in 
length, and approximately 27%% exceed 10 characters in length. These 
correspond to the significance limits of the Pascal Standard and the 
Control Data Cyber compiler. The Burroughs B6700 compiler I used has, 
of course, no limit on significance. 

Since the B6700 compiler is good in this respect, it is possible to write 
programs which work on the B6700, but which give rise to compiler error 
messages (or worse, altered and undetected scope renaming) on systems with 
limited significance. How often does this occur? Fortunately, the 
STANDARD option on the B6700 compiler checks the possibility of any such 
events. The answer seems to be: surprizingly often. In previous programs 
I have seldom been able to escape changing an identifier name to avoid 
problems elsewhere, and it happened twice in this program. The instances 
were: 



number of events 
NumberOfPlates 



{an integer variable} 

{a constant, altered to NoOfPlates} 



Display Type {the type of the display register} ^ 

DisplayTime {a procedure^ altered to DisplayATime} 

I draw the conclusion that any compiler that has a significance limit greater 
than 8 characters ought to perform the same checks; software I receive from 
elsewhere often exhibits the same problem. I also conclude that the 
8-character limit is a mistake, and should never have been introduced into 
Pascal. 

The B6700 compiler also produces as a by-product of this checking a list 
of instances of renaming under the scope rules. None were reported in this 
program at all, which surprized me. Usually i and j crop up with mono- 
tonous regularity, but in this case it appeared that the lesser numeric 
orientation and the program structure minimized this. 

Letter Cases 



As the examples above indicate, the compiler accepts either letter case in 
accordance with the Pascal Standard, and I write programs in predominantly 
lower-case letters. I dislike the practice of capitalizing the reserved 
words as it has a bad effect on readability for me. However, during the 
course of this program I found myself falling into a practice which I had 
never used before, but which seemed to be useful. I offer it as an 
example of the differences in personal style that can arise with a little 
thought devoted to stylistics. 

The practice I adopted, more or less by chance at first, was to write 
variables in all -lower-case, as in nvmbero f events , but constants, types, 
and procedures in mixed-cases, as in NoOfPlates or Display ATvme . 
Rationalizing it after the event, I noted that variables often have 
shorter and less complex names than other objects and thus may have less 
need of extra lexical cues, and procedure names are often the longest and 
most complex. Sometimes these are a verb-phrase, while variable names 
are more noun-like. 

The practice improved my understanding of the program, mainly because I 
could detect in expressions which were variables and which constants. 
Such slight cues are worth a lot more to me than emphasizing reserved 
words (which I know very well). Example: 

if (time = LastMinuteOfDay) then begin 
I am not yet sure whether this will be a stable feature of my future style. 



Line Layout 

I used my usual line layout and indentation rules, reported in Sale [1978] , 
and had no need to edit or correct any semicolons or ends. A consistent 
style minimizes these trivial but annoying errors. 

Comments 



I classified the comments into three categories: 

(a) Marker comments , used to assist picking out corresponding 
points in a program, typically attached to an end to show 
what it is the end of, or to pick out a procedure name by 
underlining. Little semantic content. 

(b) Procedure heading comments . These have considerable 
semantic content, and outline the purpose of the procedure. 

(c) In-text comments , which either give additional information 
relating to the execution, or explain definitional points. 
They vary all the way from a hint: 

{Midnight changeover] 

to an assertion: 

{Re-establishing the invariant: 

Ri = "All events up to and including the one pointed 
to by the 'preceding* pointer are due to occur 
before or simultaneously with the new one. Also 
if state=Exit there are no more records that 
satisfy this criterion. " 

The comment characteristics are shown below. 



Kind of comment 


no 


lines 
spanned 


% lines 
spanned 


Marker 
Header 
In-text 

TOTAL 


36 
18 

67 

121 


36 
67 
87 

190 


19% 
35% 
46% 

100% 



The closing comment marker ("}") was always the last non-blank character 
of the line it appeared on. Since one-line comments make up 80% of the 
total number of comments, and 51% of the total number of lines spanned, 
here is support for the idea that comments delimited by end-of-line 
require no more keystrokes than bracketted comments. (Apart from other, 
better, reasons for preferring them.) 

The distribution of comment lengths, shown in Figure 2, emphasizes this. 
It is certainly influenced by my habit of putting correctness assertions 
and hints in the code body, thus reducing the size of procedure header 
comments. (The comments often share lines with code, so do not make the 
mistake of assuming that the program contains 190 lines of waffle together 
with the 157 blank layout lines) . 




Procedures and Functions 

Having arrived at a suitable transformation level by eliminating tasks from 
the conceptual solution and substituting interrupt -driven procedures (Yes, 
I know they aren't standard), the resulting program had 18 procedures/ 
functions, including the main program. Other statistics are: 



* Procedures 
15 (83%) 


Functions 
2 (11%) 


Program 
1 (6%) 




Parameters : 



13 (76%) 


1 

3 (18%) 


2 

1 (6%) 



The low frequency of parameters is explained by the nature of several of 
the procedures: they are refinements. In fact six of the parameterless 
procedures are called from only one place each, and a microprocessor 
engineer might well apply a transform to put their code in-line and their 
local data in the caller's stack. Personally, I exert pressure on compiler 
suppliers to make their compilers do it automatically: detecting the once- 
only call is not difficult for a multi-pass compiler. On the B6700 such a 
transformation would save 54 bytes of code out of a total of 2304 (2.3%), 
and would also speed up the execution slightly. 

The maximum level of procedure nesting is three , and this occurs 7 times. 
This is astonishingly low for me, since my refinements often creep up 
into the 10 to 12 levels deep. Analysing it after the event, I conclude 
that the low nesting level here is due (a) to the complexity of this 
problem being in task interlocking, not in algorithm complexity, and (b) 
to several refinements being pushed to outer levels for use in several 
contexts (by the sub-tasks) . 



Types 

As might be expected, real numbers are not needed in this problem. 
The usage of different types in the program is shown below: 





definitions 


uses in var or type 


boolean 


(1) 


2 




integer 


(1) 







char 


CD 


6 




real 


(1) 







user-defined scalars 


6 


7 




subranges of scalars 


1 


1 




subranges of integer 


9 


30 




records 


1 


1 




arrays 


3 


8 




sets 


4 


8 




pointer types 


1 


4 




files 











The absence of integers arises naturally because no negative numbers occur 
in this problem, and because the range of every integral value is predict- 
able. Only innate laziness allowed one of my favourite types: 



Natural = 



Maxint; 



in to substitute for the type of a value parameter which ought to have had 
a special type declared for it in the outermost block: 

TuioDaysWorthOfMinutes = .. 2879; {2*24*60 - 1} 

I salved my conscience by adding a comment to this effect, which probably 
took more time doing it right... 

Of some interest is the ratio of user-defined scalars to uses of pre- 
defined types (7 : 2). This is a measure which I take as roughly indicative 
of a switch from other language thinking to Pascal (or abstract) thinking. 

The problem isn't big enough to draw any more conclusions. 

Boolean expressions 

Some people, on seeing my programs, adopt a knowing look and say, "You used 
to be a Fortran programmer, weren't you?" and point to an example like: 

if ( eventlist = 0) then begin 

Since this is total misunderstanding, it deserves a few words. I usually 
put parentheses around every relational expression I write. The prime 
reason is that I find it greatly improves the readability of the program 
in that the limits of some complex expression can be more readily found, 
as for example in: 

if (modulo counter in pattern [plate [i]]) then begin 

But having done this for a long time, it confers several other benefits: 

(a) I almost never make mistakes in writing expressions which the 
Pascal syntax will parse in a way I didn't intend. (The few 
priority levels are well-known as a trap) . 

(b) I have to devote less thought to trivia while writing programs, 
and therefore more thought to correctness proofs, simply 
because I use codified rules. 

To illustrate the point, the same thing happens in the following example: 

IsTlBeforeT2 := (tl < t2) ; 



summary 

The purpose of this little letter is to give you some insight into 
some personal stylist ics in the hope that you will examine your own 
equally carefully and ask yourself whence they came and why. 
Pascal is no language for nongs who mindlessly copy others. I also 
hope it may give some ideas to compiler-suppliers on the sorts of 
things I do. If you ever want to please me, here are some hints. 
Preserve the abstractions and make any limits on what I can do at 
what I call virtual infinity.... 



j$S^ 
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Open Forum for Members 



Y<llC UniVCrSlty New Haven, Connecticut 06510 



SCHOOL OF MEDICINE 

333 Cedar Street 

Section of Laboratory Medicine 



January 23, 1980 



Andy Mickel 

University Computer Center 
University of Minnesota 
Minneapolis, Minnesota 55455 

Dear Andy: 

Yesterday I called and spoke to Rick Marcus about a bug I have found in 
ID2ID. My version is attached, together with the data that showed the 
fault, and the symbol table progression in the original system. 

Please consider this as a letter to PUG, and pass it on accordingly, I 
attach a second copy for the purpose. 

On Pascal Standards, I have several observations. First, based on Bob 
Fraley's HP3000 Pascal Compiler, I feel the need for a standard procedure 

PROMPT (FILE) 
which will have the effect of a writteln without causing a line-feed or 
carriage-return. This is required for interactive use, where the under- 
lying system buffers output. The procedure will flush the buffers* 
Wherever the I/O system is direct, the procedure is not needed and need 
not generate any code. 

I firmly approve of the "otherwise" clause in the case statement, and 
also feel it should be extended to variant records. I.E. 



A 


Record 


Case B : 


Type of ( 


C : 


Ctype ) 


D : 


Dtype ) 


Otherwi se : 


Elsetype )) 



^DISPOSE is often replaced by Mark/Release, which should be an available 
option in the standard. DISPOSE must always require a garbage collector,/ 
and thus a good deal of run-time. However, systems not implementing 
dispose should generate a null procedure for source compatibility, and 
similarly for Mark/Release, Note that implementation of Mark/Release 
on systems that provide (new) storage to various processes from a common 
pool must implement the equivalent of dispose for a release. However* 



Andy Mickel 



January 23, 1980 



these systems are complex by definition, and thus a full DISPOSE is 
probably not excessive. In this case release effectively signals the 
garbage disposal system to function. 

An extension sorely needed is simple arithmetic in constant definitions, 
allowing all compile time constants to be slaved to a single definition. 
Similarly the use of ORD and CHR functions in constant definitions 
would be useful . 

Implementation of goto's out of procedures is virtually impossible (at 
reasonable cost) on many machines. The HP3000 is an example. I would 
therefore recommend that the standard does not require these, and that 
they be considered an extension. Logically, I have never found such 
goto's necessary, and in addition such use customizes code segments to 
any overall program, preventing direct recuse. 

I am also running the USCD Pascal System, VER 11.0. Users should be 
warned that, as supplied, this does not detect integer overflows, (at 
least on 8080/Z80 Systems) , and that the complement of -32768 is 0!! 
with no warning .Some stack overflows can occur without trapping in 
addition. My revised interpreter cures these problems, when many 
system programs proceed to crash on integer overflow, and thus the over- 
flow check has been made switchable. The USCD System does not detect 
EOF on the remote files, and thus cannot read text files remotely with- 
out considerable contortions. 

Sincerely, 



Charles Falconer 

Chief Instrument Engineer 



CF:tmm 
Enclosures 



Carnegie-Mel Ion University 



Department of Computer Science 

Schenley Park 

Pittsburgh, Pennsylvania 15213 



January 29, 1980 



leading blank. 1 suggest rewriting the specification 
so that this is clear - by noting that rather than 
1 leading blank is required. 

I have seen the notation Write(Val: 1) used to mean: Use the 
smallest possible fieldwidth. A cute use of the specifications, 
but its obscurity is not in the spirit of the language. Perhaps 
Write (Val) ought to print Val in the smallest fieldwidth possible 
(no leading blanks either!) while a fixed fieldwidth would be used 
only if specified. This would unquestionably be the most pleasant 
solution for most users, especially novices. 

The Write (Val: 1) idiom is deficient for another reason. Many 
implementors have chosen to implement output in an undersized field 
by writing out asterisks. A good case can be made for this, and I 
suspect many Pascal implementors will continue to do so despite the 
standard. 



A.M. Addyman 

Department of Computer Science 

University of Manchester 

Oxford Road 

Manchester M13 9PL 

England 



Sincerely, 



Ellis Cohen 



Dear Professor Addyman: 

I was delighted to see the proposed Pascal standard in Pascal 
News . In general, I think the proposal is excellent. However, 
there were a few points that troubled me. 

- Textfiles. 6.4.24 seems to require that every textfile 
end with a linemarker. Is that intentional? If so, 
must closing a file(used for writing) force a linemarker 
to be output if one does not already end the file? 

- Pages. It seems bizarre to include a standard Page 
procedure without specifying the effect on the file 
or including a procedure to test for end of page , 

I propose making the procedure optional, but if it is 
included, require that a page marker be written which 
is (like a linemarker) read as a blank, and that an 
Eop (end-of-page) predicate be included as well. 
Additional questions: Should Eop imply Eoln? Should 
Page force a Writeln automatically? 

- The CASE statement. I must say I am surprised the 
OTHERS clause was not included in the standard. I'm 
equally unhappy (but less surprised) that subranges 
were not to be permitted in the case-constant list, 

- Numeric output. 6.9.3 requires a leading blank for a 
number that fits in the output field, while no leading 
blank is required if it does not. So, in the case of a 
number whose width is the same as the fieldwidth, the 
number ^Ls printed out in just that fieldwidth without a 



-ft 



Dear Pug 



BRITISH COLUMBIA HYDRO AND POWER AUTHORITY 



Red Stripe Computer Trailer 

Gas Division 

3777 Lougheed Highway 

Burnaby, B.C. 

V5C 3Y3 CANADA 



I wrote a while ago about banning the marriage of Pascal and EBCDIC 
unonMoM 2£l/?n.? d ! ce ? t character set ^0"^ have the following property 
M 0RP('9')-0RD('0') should be 8" That should read "0RD(»9' )-0RD('0' ) should be 9" 

If you decide the publish that letter, please correct the mistake.' 
Please do not publish this letter. 



Thaaks 




WINTHROP PUBLISHERS, INC, n&unster st., Cambridge, mass. 021S8 tel: 6i7-868-i7S0 



January 8, 1980 



Professor Andy Mickel 

University Computer Center 

227 Experimental Engineering Bldg 

208 SE Union Street 

University of Minnesota 

Minneapolis, MN 55455 

Dear Andy, 

I'm a little concerned about some possible unintended 
effects of your brief book reviews section on page 8 
of Pascal News , No. 15. 

You quoted a table from a review by Jan Hext, of the 
University of Sydney, comparing Pascal textbooks in their 
coverage of the language. I am concerned that, taken 
out of context, that table may scare potential readers 
away from our book by Conway, Gries, and Zimmerman, 
A PRIMER ON PASCAL, the second edition of which is due 
this spring. 

There is no question that the coverage of Pascal in that 
book is not nearly as extensive as many other books 
(although in the new edition it will be somewhat more so), 
but taken out of context, it looks like you are rating the 
book in general as "poor." The reviews in my files 
indicate, of course, that the book is arguably the best 
introduction to programming using Pascal as a vehicle, 
and for such a use might well be much more appropriate than 
a book which is a more thorough rendering of the language 
but less helpful in learning to program. So, while I do 
not quarrel for a moment with Professor Hext's analysis 
of what this book is not , I wish to rush to the barricades 
to reaffirm what, on the other hand, it is . 

Thanks for listening. 



Best regards, 

CUcfc__ 



Charles F. Durang 
Editor, Computer Science 

CFD/mw 



SOPHIE DAVIS SCHOOL OF 
BIOMEDICAL EDUCATION 



THE CITY COLLEGE 

OF 

THE CITY UNIVERSITY OF NEW YORK 

NEW YORK, N.Y. 10031 

Wednesday, January 30th, 1980 



(212)690-6629, 8255 



Rick Shaw 

PASCAL User's Group 

Digital Equipment Corporation 

5775 Peachtree Dunwoody Road 

Atlanta, Georgia 30342 



Dear Rick; 




Enclosed is my personal check for $26.00; please enter my subscription/ 

Iso send the 

Xeroxing and 

.. A . , - - ~~ r ies of your 

extinct issues 1-8. 

In our mammoth CUNY University Computer Center (Amdahl 470/V6 and IBM 3033 
under 0S/MVT and ASP; IBM 3031 under VM and CMS), Stony Brook PASCAL 1.3 is 
standard, and Version 2S was just added to a test library last week. (I gather 
from the documentation that both are rather limited in complex applications - 
for example, no external files...) Although I know of no campus among our 20 
where PASCAL is the prime teaching language, faculty and student use is clearly 
on the rise; we've just brought up 2 PASCALS on a PDP-10 here in the CCNY 
Science Building. 

I am involved in bringing up an orphan Z-80 microcomputer from the defunct 
Digital Group in Denver; besides opscan test grading, the primary application 
will be bibliographic citation retrieval from a hybrid collection of about 8,000 
articles. I am presently working up the necessary software package for this 
operation in PASCAL, using bit-string inverted lists hung from a B-tree. 

With the possibility of a brief trip to Switzerland this April, I have 
considered arranging a visit with Professor Wirth; if anvbodv else has done 
so, expecially recently, I'd love to hear from him as soon as possible. PASCAL 
was my native language at SUNY Stony Brook, and I'm yery thankful for that. 
I m eager to meet other New York City PASCAL users. 

Sincerely yours; 



a 



!x<. 



Alan N. Bloch, M.P.H. 
CCNY Biomed J 910 CI 



end . 



AN EQUAL OPPORTUNITY EMPLOYER 



KERN INSTRUMENTS, INC. 

GENEVA ROAD • BREWSTER, NEW YORK 10509 



Kern 

I \ SWISS 



TELEPHONE: 
(914) 279-5095 

TELEX: 
969624 



January 15, 1980 



Mr. Rick Shaw 

Digital Equipment Corporation 

Pascal User's Group 

5775 Peachtree Dunwoody Road 

Atlanta, GA 30342 

Dear Rick: 

While renewing my subscription, 
a few words. 



I am taking the opportunity to say 



I have used two Pascal systems in my work here; initially, a 
Northwest Microcomputer 85/P with UCSD Pascal, and now a PDP-11 
with RT-11 operating system and OMSI, Pascal I version 1.1. Both 
have advantages (and disadvantages). The UCSD operating system 
(with CP/M utilities) was fantastic, especially the editor. How- 
ever, I/O handling (I wanted interrupts) was poor. With RT-11, I 
can use all the I/O facilities of this excellent operating system, 
but OMSI doesn't support them very well. Hopefully, this will be 
fixed in version 2 which is due any day now. I'm also disappointed 
that several Pascal features I used quite heavily with the UCSD 
system are not implemented in OMSI Pascal I, particularly the Pack 
and Unpack functions. These are very convenient for formatting and 
unformatting I/O records used in certain peripherals. 

I see almost weekly announcements concerning new Pascal compilers 
and machines. Now that most of the established computer manu- 
facturers have taken up the cause, we can say that Pascal has 
arrived. So much so in fact, that I would not have resubscribed to 
PUG if not for Arthur Sale's recent issue describing the Validation 
Suite. Congratulations to Prof. Sale and his group. 

Now it's up to us Pascal ers to encourage the compiler writers to 
meet the standard and implement any extensions in an acceptable 
manner. 



Good luck, Rick! 



Sincerely yours, 

KERN INSTRUMENTS, ifiC. 



T. P. Roberts 

Photogrammetric Systems Engineer 



TPR:pm 
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BRITISH COLUMBIA HYDRO AND POWER AUTHORITY 



970 BURRARD STREET 
VANCOUVER, B.C. 
V6Z 1Y3 

TELEX 04-54395 

1979 December 31 



Dear PUG 



re: outlawing EBCDIC and Pascal marriage 



I have tried to write some text tidying routines with the 
University of B.C. Pascal compiler under MTS. It uses 
EBCDIC as its underlying code. Arrgh! 

ORD('Z' )-ORD( 'A') should be 25 in all decent Pascal implementations. 
ORD('z')-ORD( 'a' ) should also be 25. There should exist a magic 
number m such that you can do lower to upper case conversions. 
ORDrrj-ORDCO') should be 8. (Even EBCDIC gets that right!) 
ORD(' ') should be less than ORD('A'), ORD('a'), and ORD('O'). 

ASCII has these properties. EBCDIC does not. It is thus difficult 
to write portable code. 

I suggest that any Pascal standard insist that an "excellent" rated 

compiler provide a compile-time switch to insist that all internal 

character codes be ASCII even if this means translation in and out. 

Alternatively, Pascals that live in an EBCDIC environment that wish 

to manipulate all 256 characters should work internally on a 

modified EBCDIC that has the above nice properties. A compiler 

that could not provide this option could only obtain a "reasonable" rating. 

To indicate the horrors of EBCDIC, consider that none of the following 
code works as you would expect. 



if C in ['a'.-'z'] then Si; 
for C := 'A' to 'Z' do S2; 



vF C >= 'a' aniC <= 'z' then S3; 



It is also impossible to write (I hope I am wrong) decent hashing 
algorithms and random number generators that are truly portable (ie. 
give the same answers in all implementations). Perhaps "excellent" rated 
compilers should also provide some extra builtin functions for these 
tasks. It wouldn't hurt to define their names and parameters now. 



'$06^ &6e-Y 



Roedy Green 



[g COMPUTER SCIENCE PRESS INC. 



91 25 FALL RIVER LANE 
POTOMAC, MD. 20854 
[301 ] — 299-2040 



November 27, 1979 

Dr. Andy Mickel 

Editor 

Pascal Newsletter 

University of Minnesota 

University Computer Center 

227 Experimental Engineering Building 

Minneapolis, Minnesota 55^.55 

Dear Dr. Mickel: 

In the 15th issue of Pascal News on page 8 you inadvertently omitted 
the list for our hook PASCAL: An Introduction to Methodical Program- 
ming by William Findlay and David Watt in an article comparing the 
available Pascal books. It was listed in the table at the bottom of 
the page. We would appreciate it if you would correct this ommission. 
Pascal: An Introduction to Methodical Programming is published for 
the United States and Canada by Computer Science Press, Inc. @ $11.95. 
it is available and published throughout the Remainder of the world by 
Pitman Publishing Ltd., 39 Parker Street, London, England WC2B 5PB. 

In its first year Computer Science Press has sold over 12,000 copies of 
Pascal: An Introduction to Methodical Programming within the United 
States and Canada. We also believe that a much more meaningful com- 
parison and evaluation of books can be obtained by the basis of the 
universities and colleges which are using it. Our book has been 
adopted at over 50 schools within the United States and Canada including: 



Arcadia University 

Albright College 

Brock University 

Broome Community College 

California State University at 

Long Beach 
Cariboo College 

Case Western Reserve University 
College of William and Mary 
Dalhousie University 
Dickinson College 
Fairleigh Dickinson University 
Framingham State University 
Iowa State University at Ames 
John Brown University 
Kansas Wesleyan University 
E. R. Lauren University 
LeTourneau College 
Loyola University 



Lucas College 

Marian College 

Marquette University 

Merritt College 

Montana State University at Bozeman 

Moravian College 

Morningside College 

North Carolina State University at 

Raleigh 
Northampton Community College 
Northeastern University 
Plymouth State College A 

Purdue University at West Lafayette 
Rollins College 
Rosemont College 
Sonoma State College 
Southern Methodist University 
Stanford University 
Temple University 



|g COMPUTER SCIENCE PRESS INC. 



91 25 FALL RIVER LANE 
POTOMAC, MD. 20854 
[301 ] — 299-2040 



Texas Technological University 

Thames Valley State Technical Coll. 

Towson State University 

Union College 

U.S. Military Academy at West Point 

U. of California at Berkeley 

U. of Chicago 

U. of Houston at Clear Lake City 

U. of Maryland at College Park 

U. of Massachusetts at Amherst 



U. of Mississippi at University 

U. of Oregon at Eugene 

U. of the Pacific at Stockton 

U. of Pennsylvania at Philadelphia 

U.of Saskatchewan 

U. of South Carolina at Columbia 

U. of Southern California at Los Angele 

U. of Texas at Austin 

U. of Utah at Salt Lake City 

U. of Washington at Seattle 

Villanova University 



WE INVITE ALL COLLEGE PROFESSORS WITHIN. THE UNITED STATES AND CANADA 
TO WRITE TO COMPUTER SCIENCE PRESS AND REQUEST A COMPLIMENTARY COPY 
OF PASCAL: AN INTRODUCTION TO METHODICAL PROGRAMMING . Please write 
on school stationary, identifying the current text, the course name 
and number, as well as the anticipated annual enrollment, and we will 
be happy to let you determine for yourselves which is the best book 
for teaching Pascal. 

We would also like to call to your attention our short course program 
offered through our Computer Science Education Extension Division which 
will offer 2-3 day courses on Pascal on: 

March 2^-28 at San Francisco 

May 18-19 at Anaheim (preceding the NCC) 



Thank you. 



Sincerely yours, 



£cu%J**^*l» Jb &**Ldti**asH^ 



Barbara B . Friedman 
President 



BF:cw 
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PRINDLE AND PATRICK ARCHITECTS: PLANNERS 

•MEMBERS: THE AMERICAN INSTITUTE OF ARCHITECTS" 

October 17, 197 9 

Pascal User's Group 
c/o Andrew hickel, 
University of Minnesota, 
227 Experimental Engineering, 
Minneapolis, tafci 55455 

Re: Pascal User's Group and Pascal Newsletter 

Dear Sir: 

I would like to get information on the Pascal User's Group, 
especially, as soon as possible to get the Pascal Newsletter, 
including back issues if possible. I would like to join the 
organization and find out all I can as I am contemplating 
committing this system to extensive use of Pascal, although I am 
not at present a Pascal user. I would like to learn something 
about the availability of Pascal software, either to swap or 
sell. 

The company I work for is an architecture firm which has a 
PDP-11/34 running RT-11 and TSX (TSX provides several virtual 
RT-11 single job monitors with some limitations and some 
additions, if you are familiar with DEC's RT-11.). Our 
applications are Accounting, Word Processing, and some statistics 
and simulation. We hope someday to get into some graphics. 
Right now there is an awful lot of awful assembler stuff around 
here which must one way or another be transformed into something 
more portable. 

Another bit of background is that I am one of the first users 
of the Whitesmith's Ltd. C compiler, which satisfies the 
specification given in Kernighan and Ritchie's book with one 
addition, which is that different "typedef's can have elements 
with the same name. I.e. there can be an A.x and a B.x. 
According to Kernighan and Ritchie, this is not allowed in 
regular C, which is very peculiar (It can be disabled in 
Whitesmith's C for compatibility). Whitesmith's also says they 
have been using their own UNIX-compatible O.S. (will run UNIX 
binary programs) for about a year now, and will soon be selling 
it for much less than the cost of UNIX. I estimate that one 
(such as a very serious hobbiest) could have a quasi-UNIX system 
within a year for under $10,000. The rub is that Bell Labs is 
currently trying to make it appear as if UNIX user's society 
software cannot be spread around to non-members , at least that is 
the impression I get. But a number of sources from DEC to 
Yourdan, Inc., to Whitesmith's tell me they don't have a legal 
leg to stand on. But who will get the ball rolling? 

I don't know if all this interests you or not, but I thought 
there was a fair chance it might, and that you might be able to 
lead me to some help in finding or helping to establish services 
that would do for C what you are doing for Pascal. My own 
impression is that C and Pascal are quite complementary, C being 
a better systems language, and Pascal being better for many, or 
even most applications. 



Sincerely, 



\K>rS^^ 



Hal Morris 
System Manager 




BRITISH COLUMBIA HYDRO AND POWER AUTHORITY 



Red Stripe Computer Trailer 

Gas Division 

3777 Lougheed Highway 

Burnaby, B.C. 
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(604)298-1311 loc 372 



1979 November 20 



Dear Pascal Standardizes: 



The key beauty to Pascal is that if you take a valid Pascal 
proaram and randomly change/delete/insert a character, there is a 
very hioh probability that you will have an invalid program. There 
is also^a high probability that this invalidity can be detected by 
the compiler~at compile time. Ie. Pascal will catch typos. 

One of the few exceptions involves the semicolon. Randomly 
sprinkling semicolons can change the intent of a program as described 
in the User Manual and Report on page 26. 

11 P then ; begin SI ; S2; S3 end is a surprise 

To get around this problem (and to force everyone to use the 
semicolon as a separator instead of a terminator as God intended), I 
suggest making the empty statement invalid. In its place we would 
invent the null statement. 

The null statement would make programs easier to read: 
11 P then null else SI 




Other than that, Pascal is perfect and should' be left alone. 
However, why not let people extend the language in any way they want 
by using pre-processors written in Pascal that produce Pascal code. 
Now alTwe need is an ingenious general purpose pre-processor to 
implement any goody your heart desires. 



Love d \ 
Roedy Green 



Hj 



The UNIVERSITY of WISCONSIN- LACROSSE 



LA CROSSE, WISCONSIN 54601 

UNIVERSITY COMPUTER CENTER 

JOHN C. STORLIE, DIRECTOR 

HARVEY FOSSEN. ADMINISTRATIVE SERVICES 
JOHN NIERENGARTEN. ACADEMIC SERVICES 



(608) 785-8000 

785-8029 



July 2, 1979 



Mr. Andy Mickel 

Pascal User's Group 

University Computer Center: 227 EX 

208 SE Union Street 

University of Minnesota 

Minneapolis, Minnesota 55455 

Dear Andy: 

Per your request for information on what we're doing here with Pascal, I 
have the following. 

■ 4- 

We have a Hewlett Packard ,3000 computer system which among other things 
supports undergraduate computer science instruction. In the past six 
months we have installed the contributed compiler from HP labs made 
available to the HP General Systems Users Group. The current version is 
fairly complete, although it is somewhat slow because it is a P-code 
system, which first translates into SPL (system programming language) and 
then compiles and executes the SPL. 

Nonetheless, for pedagogical reasons our computer science department is going 
to teach Pascal. In fall 1979 we will introduce Pascal to three sections 
of Computer Science 121, Programming in Algorithmic Languages, replacing 
FORTRAN. This will introduce about 100 Computer Science students a semester 
to it and will provide them with a tool which they will use through much of 
the rest of their curriculum. Pascal meets a long unfulfilled need here 
for a block structured, high level language for teaching which enables one 
to teach proper programming structure. 



Sincerely, 



.. .//. 



yfc^ 



John A. Nierengarten 
Assistant Director 
Computer Center 

JAN:lh 

c.c. J. Storlie 
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25th October, 1979 



Andy Mickel 
Pascal Users' Group 
University Computer Centre 
208 SE Union Street 
University of Minnesota 
Minneapolis. MN 55455 

Dear Andy (-if I may?), 

Thank you for returning my call yesterday regarding the 
small print size of the PUG Newsletter. 

I find your reply that the reduced print size will 
continue disappointing, of course. 

Your remark to my secretary that you have only had about 
four or five complaints about print size is of uncertain value as an argument. 
How many people, disgusted by the print size, did not trouble to call? Bearing 
in mind that your distribution is world-wide, many people rather distant from 
Minneapolis might be slightly more reluctant to call than I was; I very 
nearly did not call . 

I am always rather disturbed at the insistence on 
uniformity in the name of technology, or efficiency, or cost. Surely people should 
come first? Why not leave a few print-outs at full size, and ship those to the 
feeble-sighted? You save on the cost of reducing and binding, at the expense of 
a little extra organization. 

I (to appreciate that yours is a volunteer effort, run 
with minimal staff. But are not PASCAL and its devotees worth it? 



Yours sincerely, 



/ 



-,J^ 



Colin Park (Ph. D) 
(Assistant Director). 

P.S. In the case of PASCAL, some of us may even be prepared to pay a little 
more for the privilege of not straining our eyes. 
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Pete Goodeve 

3012 Deakm Street, apt D 

Berkeley, Calif. 94705 

1979 November 9 



Andy Mickel 

Pascal News 

University Computer Center 

227 Experimental Engineering Building 

208 Southeast Union Street 

University of Minnesota 

Minneapolis! Minnesota 55455 



Dear Andy: 

Willett Kempton mentioned, in his letter to you of a few 
months back, that I was finishing up a new Pascal system for Data 
General AOS installations, and ever since then I have been 
getting around to sending you a proper report. As the system has 
been stable now for over a month, it is obviously high time to 
finally get this note written. 

We have actually had a version of AOS Pascal out in the field 
for nearly a year now, but this is basically the Lancaster P4 
Nova RDOS Pascal with a run-time system modified to mate with AOS. 
The new edition is extensively rewritten, at both the run tine 
and compiler levels. 

The run time interpeter now takes full advantage of the 
Eclipse's instruction set (rather than being Nova compatible), 
has completely revised file-variable management and has been 
expunged of the few existing (and actually rarely encountered) 
bugs in the Lancaster original. 

The compiler is now considerably closer to the (draft) 
standard than is P4: I had initially hoped to remove all the 
essential discrepancies, but a couple still remain due to time 
aBd budget limits. A couple of non-standard features — in the 
form of some additional predeclared procedures (modified from the 
Lancaster original) — improve the links to the external world 
somewhat. Tnese are: a) abnormal program termination with HALT; 
b) random access of the components of any Pascal file via 
GETRANDOM and PUTRANDOM. This compiler — liKe its Lancaster 
parent — supports external procedure declarations, and as these 
may be written in either Pascal or assembly language, the user 
has considerable freedom in adding any system functions etc. that 
may suit him. 

I should point out that what Lancaster calls "P4" has been 
considerably extended from the original Zurich version. In 
particular, it embodies full, typed file-variable facilities, 
including external files. I have had the gall to label the new 



compiler P5 to avoid some of such guilt by association. 
Restrictions that have now disappeared include: 

1) Upper-case-only ASCII: lower case may now 
be used freely in program text; it is not 
distinguished from its upper case equivalent. 
The standard brace convention for comments is 
allowed. 

2) Tiny string constants (originally 16 chars max): 
the limit has been (arbitrarily) extended to 120 chars, 
but compiler heap space used corresponds to actual length. 

3) GOTOs within procedures only: the full Pascal 
standard is now implemented; this was felt to be 
important for the occasionally vital "panic sequence". 

4) No second field-width specifier for real output: 
full standard formatting is now implemented. 

Other changes to the compiler — such as increased set-size 
— are really only relevant to this implementation, and I will 
leave them aside here, but one other internal change may be of 
more general interest. It turns out that while the stacK frame 
size allocation mechanism used in the original P4 was quite 
adequate for an implementation where all stack elements are the 
same size, it doesn't really cope with the situation of differing 
sizes. In brief, when generating a P-code instruction that does 
not have a fixed operand type, the compiler didn't take the 
actual type into account when allocating' space on the stack; 
instead, it would.allocate the largest possible size if the 
instruction was a i% "pusn" type, and release the s_ma_l.le.s_t possible 
in the case of a "pop". This meant that the longer the procedure, 
the larger the stack frame it apparently would need, while in 
fact most procedures really need very little in the way of 
temporary space. This defect became especially severe when we 
went to 8-word setsl The P5 algorithm is exact, keeping proper 
track of tne amount of space needed or released by each 
instruction. 



Like a number of other systems around, the approach to 
generating an executable Pascal program is for the compiler to 
generate a fairly low-level symbolic "p-code" from the original 
source; this is converted to binary form and bound with the 
run-time library modules to create an executable file; the whole 
sequence of course follows automatically from a single command to 
the operating system by the user. I don't intend to get into 
discussion here of the relative merits of interpretation versus 
compilation to machine code, although the system seems to perform 
very creditably against DG Fortran, for instance. The main 
advantage of this approach as I see it is its modularity: if one 
later wants true compiled code out of the system, there is no 
need to touch the compiler at all > P-code appears to translate 
very smoothly into many machine instruction sets (including that 
of the Eclipse) and in some cases this may be possible using an 



existing macroassembler. (In fact, for simplicity and because of 
tne slowness of macro expansion, in our system even the 
translation of P-code to its packed form is mostly done by a 
translator written in Pascal.) Certainly, if the P-code is 
complete enougn, it snould be reasonably simple to produce 
translators and interpreters for different machines, using 
exactly; the same compiler. 

Because first Lancaster, and then ourselves, 
lacks in the Zurich P4 P-code in the ancillary info 
one would liKe to have when generating a binary ver 
code, an attempt has been made in the P5 variant t 
tne information that a translator program might nee 
entirely independent of the target machine. The P- 
tions and their formats are unchanged from the orig 
for the M inclusion tt of the new facilities, but a new 
— the "directive" — has been added. Directives a 
indicate such things as procedure entry labels — t 
tneir original Pascal identif iers» o this sort of ex 
is useful in building "memory maps" or other debugg 
translation. External procedure declarations and e 
also have their own directives, so that suitable 1 
up when the modules are bound into executable form, 
directives supply the program name and so on, and 
numbers now appear with the instruction counts reco 
P-code. 

I had intended to enclose a specification sheet for the 
Implementation Notes of the "News", but I think we should be sure 
that you receive it in final released form, so I will let Gam-na 
Technology supply that item. If anyone is interested in more 
details in the meantime, they are welcome to contact: 
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GAMMA TECHNOLOGY, INC. 
2452 Smbarcadero Way 
Palo Alto, Calif. 94705 
(415) 856-7421 



Sincerely, 



# 



PATTERN ANALYSIS & RECOGNITION CORP. 



228 LIBERTY PLAZA 
ROME, N.Y. 13440 

TEL. 3 T 5-336-8400 



15 February 1979 



Mr. Timothy M. Bonham 
D605/1630 S. Sixth Street 
Minneapolis, MN 55454 

Dear Tim: 

I have modified the PDP-11 pascal compiler kit (version 4) dis- 
tributed by DECUS and by Seved Torsterdahl (see Pascal News #12, June 
1978) to improve it in several ways and would like to make it avail- 
able to interested RSX-IAS users. I have called my modified kit 
version 4.5, to avoid confusion, because version 5 is now available 
from DECUS. All of the modifications were made in order to allow the 
compiler to compile itself (until now it had to be cross-compiled 
using a DEC-10), but as a side effect my version has the following ad- 
vantages : 

1) Can be configured to have one of three different levels of 
overlaying (with correspondingly different symbol table 
space) in order to allow trading of compilation speed for 
capacity to compile large programs . 

2) When configured with lightest overlaying, overlay swapping 
time is minimal and compiler runs three times faster than 
version 4. 

3) Produces object code which is 12% smaller than and is faster 
than version 4. 

4) I corrected bugs to allow procedural parameters to work. 

5) It can compile itself in approximately 15 minutes (without 
using memory resident overlays) with all files on the same 
RP06 disk drive. 

Persons interested in obtaining a copy should contact Richard 
Cichelli or John Iobst , who will be distributing the kit (and making 
further fixes and improvements ) at the following address : 

A.N. P. A. Research Institute 
1350 Sullivan Trail 
P.O. Box 598 
Easton, PA 18042 



MC/dms 



Sincerely, ^ 
Michael N. Condict 



C*>KF 



EDP department 
Michael Evans 



Datum 
1978-10-26 
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PROBLEMS IMPLEMENTING PASCAL IN A COMMERCIAL ENVIRONMENT 

We are interested in implementing Pascal as a normal program- 
ming language in parallel with COBOL and Assembler. The current 
program development environment is - 

IBM 370/168 under MVS 

Interactive development using TSO 

Logical modular programming 

Interactive testing of modules 

Structured programming using macro COBOL (MetaCOBOL) 

Data base management using System 2000 

Applications development staff of about 70 persons 

In order to be able to use Pascal in a production environment, 
we need to know about the future of Pascal in the following 
areas - 

Standardisation/Formal is at ion 
Integration with existing systems 
Special commercial requirements 
Development environment 

Programs produced in our environment have long useful life 
times, up to 10 years. Before committing to a new language, 
we must be sure that it is going to survive that long. 

Usually this kind of guarantee is provided by a machine 
supplier who undertakes support of a number of main line 
languages. Pascal is not one of our supplier's main line 
languages. 

Another guarantee is given by a formal standardisation through 
ISO/ANSI. Pascal is in practice formalised via Wirth & Jensens 
book. More recently, the Pascal group at UCSD have taken on 
collection of Pascal extensions and modifications. Are all 
Pascal implementors going to accept and implement all exten- 
sions or is there going to be a foundation Pascal with many 
different extensions? 



Standardisation 



Various Pascal-like languages have been developed and are 
being developed. How much invested development must be scrapped 
if it turns out that one of these languages, for example 
ironman/DODl, turns out to be a standard? How easy will it 
be to automatically convert to the new language. We have 
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converted between various COBOL dialects without leaving the 
COBOL language. It ought to be possible to convert to a new 
Pascal dialect if this does not involve a complete rethink 
regarding education, programming techniques, development 
tools etc. 

One of the advantages of Pascal is the use of machine inde- 
pendent p-code. Is this standardized sufficiently that code 
from one compiler may be used with another machine which 
supports the same level of p-code? This is of interest for 
us as we envisage the use of satellite machines of various 
sizes with centrally developed programs. This development 
would be eased if tested object code could be sent to remote 
sites. 

Pascal is taught at many universities. Unfortunately, many 
of our programmers, and many of those whom we employ in the 
future, have not had the benefit of this education. Are 
educational materials, in the form of video cassettes, 
course books, examples of good programming practices available 
for Pascal? It would be of great i-nterest if we could get in 
touch with other installations, especially in Europe, who 
use Pascal in a commercial environment. 

Although Pascal can be used to implement operating systems 
and data base management systems, these functions are nor- 
mally already present in the commercial environment. Data 
already exists in some form of data base which must be 
accessed in a particular way, common functions such as date 
calculation are already implemented in standard program 
modules etc. For Pascal to be fully useable, it must be able 
to communicate with modules written in other languages. This 
communication must include being invoked by other modules 
(IMS calls to data base programs) and invoking other modules 
(IMS data base services). In addition, it is often suitable 
to divide an application into a number of separately compil- 
able modules. Pascal must therefore be able to communicate 
with Pascal modules compiled on other occasions. 

The same data structures are often used in a number of pro- 
grams. To be improve safety and simplify development it 
would be useful to use the same physical definition. Some 
kind of source library management feature with a compiler 
directing COPY function is needed in Pascal. 

Programming can be simplified if common functions are already 
coded and tested. The number of such common functions can 
become enormous if all combinations of parameter types are 
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to be catered for. This problem may be avoided if a standard 
type "THING" were available. A parameter defined as THING 
may contain any type of data. It may only be used as a para- 
meter to the standard function DATATYPE (variable) which 
returns BOOLEAN INTEGER REAL CHAR USER etc, or in an assign- 
ment statement. Execution time type checking would be needed 
in that statement but nowhere else. This admittedly breaks 
the rules of Pascal as a strongly typed language in the same 
way as GO TO breaks the rules of control structures. The type 
violation would however be well marked both in the invoked 
function and probably in the invoking function (in order to 
pass type information). It would allow such functions as ge- 
neral interfaces to external systems to be implemented in 
Pascal. 

Pascal as defined by Jensen and Wirth only defines sequential 
files. It is often necessary to be able to access a particu- 
lar record in a file, either by means of a key (indexed 
files) or by means of record number (relative or direct files). 
The use of Pascal would be eased if it were possible to pro- 
gram this in Pascal and not need Assembler routines to do it. 

Other programming languages use different formats for internal 
data. These formats are often used on existing data files. It 
must be possible to access even these kinds of data. One 
method is to implement general Pascal functions to perform the 
conversion to and from standard Pascal types. To ease the 
coding of this function, the data type THING mentioned above 
would be useful. The other method would be to support data 
types which are already supported in F0RTRAN/C0B0L/PL1 even 
in Pascal possibly with some limitations. 

Arithmetic operations often involve a fixed number of decimal 
places. It must be possible to define these fields as integer 
with decimal shift instead of risking inaccuracy caused by 
floating point errors. 

The formatting requirements for figures in a financial listing 
are many and varied. Zero suppression, credit/debit signalling, 
thousand comma insertion and floating currency sign are just 
a few of the features need. Pascal must be able to define the 
editing required when outputting numeric variables to text 
files in a way similar to COBOL' s report item PICTURE clause. 
If this is not done centrally, each implementor will find his 
own way of editing, resulting in confusion similar to that 
surrounding BASIC' s PRINT USING statement. 



Commercial programming 



The programmers involved in developing commercial programs 
are among the most expensive items used during development. 
To enable them to work as efficiently as possible, they must 
have better tools than a straight batch compiler. Combined 
with a suitable compiler, Pascal p-code "gives the ability to 
have an advanced interpreter which allows single statement 
execution, breakpoints, setting och listing global and local 
variables, statement trace and path execution summaries. When 
used in an interactive environment, these features would 
greatly ease program development. Many of these ideas are 
found in the current Pascal compiler series in Byte magazine. 

As Pascal makes it easier to write large compilable units 
than many separately compilable modules, it is essential 
that the programmer be able to find variable definitions and 
uses. A cross reference listing would be very useful. 

Occasionally, commercial data processing requires handling 
of such large data volumes that speed of operation is a 
critical issue. To allow Pascal to be used in these situations, 
it must be possible to translate p-code to executable machine 
instructions on the target machine. It may even be possible 
to optimize this machine code. The interrelationship between 
these functions is illustrated below. 
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This paper contains the ramblings of a newcomer to the Post-script 

Pascal user community. I have tried to see Pascal through 

the eyes of the business data processing department where I 

am responsible for programming methodology. I imagine that 

many of the questions have been answered earlier or rejected 

as contrary to the spirit of Pascal, in which case I apologize. 
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Pascal Standards Progress Report 
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Several newsworthy events have occurred since the last Progress Report in Pascal News #15 
(pages 90-95). In a nutshell, these events show substantial progress toward an 
international Pascal standard. (See the Progress Report in #15 for a glossary of some the 
terms used here.) 

Another Working Draft 

As expected in the last Progress Report, a fourth working draft prepared by BSI DPS/13/4 
was distributed within standards organizations in October by the secretariat of 
ISO/TC 97/SC 5 under the document number "N510 11 . (Recall that the previous draft is 
called lf N462 ff .) N510 contains a large number of changes from N462. Most of these changes 
are corrections to "obvious" errors and oversights. A smaller number of changes address 
fundamental ambiguities or other technical flaws in the Pascal User Manual and Report ; 
these changes often are more controversial than the "obvious" ones. 

As an example of the more controversial kind of change, consider the restrictions placed 
on labels to which goto-statements may refer. The User Manual and Report specifies that a 
goto may not jump into a structured statement. Although the wording in N462 was felt to 
be unclear, this was the intent of the restriction in that document. But the comments 
received from the public on this section of the draft clearly showed that run-time tests 
were required to enforce the restriction in the case of goto's which jump out of 
procedures or functions. In order to allow efficient compile-time checking of goto 
restrictions, the restrictions were tightened in N510, as described later. At the same 
time, of course, the wording was clarified in response to many comments. 

A full list of all changes between N510 and N462 would be very difficult to compile and 
explain. Rather, we hope to print in a future issue of Pascal News the next draft which 
will be based on N510. 



However, there is one very important new language feature which was introduced in N510. 
This feature is called "conformant array parameters". The feature was added to N510 in 
response to the many comments, including those from Niklaus Wirth and Tony Hoare, which 
cited as a major shortcoming in Pascal the inability to substitute arrays of different 
sizes for a given formal parameter in procedure and function calls. Because this such a 
significant and recent change, Arthur Sale has written the description which appears 
below. 
The Experts Group Meeting 

The new draft, N510, served as a basis for discussion at the meeting on November 12 and 13 
in Turin Italy of the ad hoc Experts Group. This meeting was held in conjuction with the 
ISO/TC 97/SC 5 meeting on November 14. .16. The following individuals were in attendance. 



Franco Sirovich (Italy) 
Bill Price (USA) 
Michel Gien (France) 
Christian Craff (France) 
Olivier Lecarme (France) 
William A. Whitaker (USA) 
Don MacLaren (USA) 
Fidelis Umeh (USA) 
Bengt Cedheim (Sweden) 
Marius Troost (USA) 



David Jones (USA) 
Coen Bron (Netherlands) 
Jim Miner (USA) 
Scott Jameson (USA) 
Makoto Yoshioka (Japan) 
Akio Aoyama (Japan) 
Albrecht Biedl (Germany) 
Arthur Sale (Australia) 
Emile Hazan (France) 
Tony Addyman (UK) 



The purpose of the meeting was twofold: first, to advise the "sponsoring body" (BSI, 
represented by Tony Addyman) on solutions for remaining technical issues, and, second, to 
advise SC5 on a course of action for further work on the standard. Most of the two days 
was spent on technical issues* 



Technical issues were informally divided into three categories: (1) "niggles" (or 
"obvious" problems having fairly simple solutions), (2) "local" issues which affected few 
sections of the draft, and (3) issues of greater magnitude, affecting several sections of 
the draft. Naturally, discussion centered on the last two categories. 

An example of a "local" issue (category 2) was mentioned above, namely the restrictions on 
labels and goto's. The relevant section reads as follows. 

6.8 Statements 

6.8.1 General . Statements shall denote algorithmic actions, and shall 
be executable. They may be prefixed by a label. Within its scope, a 
label shall only be used in the statement S that it prefixes, the 
conditional-statement (if any) of which S is an immediate constituent, 
the statement -sequence (if any) of which S is an immediate 
constituent, and, if this statement-sequence is the statement-part of 
a block, the procedure-declarations and function-declarations of that 
block. 



statement 



[ label ":" ] ( simple -statement | 

structured-statement ) 



The group quickly agreed both that the word "used" (in "a label shall only be used") 
should be changed to indicate the fact that the only possible use of a label is a 
reference by a goto-statement, and also that the long sentence which states the 
restrictions on references to labels should be broken down into more-easily understood 
parts. It was agreed that the intent of the sentence allows goto-statements to reference 
the label of a statement S only in the following contexts: 

(a) when the goto-statement occurs anywhere within S; or 

(b) when the goto-statement occurs anywhere within the if-statement or case-statement of 
which S is one "branch" or component statement (e.g., the goto may occur anywhere in the 
else part of an if-statement and still reference the label on the then statement, but not 
a label within it); or 



Also evident was significant interest in extensions to Pascal within several countries, 
especially France, Germany, the Netherlands, and the United States. Therefore, any future 
extended standard must be developed in cooperation between the interested national groups -^ 
as a longer-range project. This project undoubtedly will involve the newly-formed Working 3> 
Group discussed below. ^ 

r~ 

The SC5 Plenary Session ^ 

The Experts Group sent two resolutions to SC5 for approval. The first resolution, which 
passed SC5 without opposition, states that Tony Addyman should revise the Pascal draft ^ 
(N510) according to the agreements reached by the Experts Group, and that this revised "^ 
draft would be registered as a Draft Proposal for voting. What this means is that some 
time in the next few months the revised draft will be distributed to SC5 voting members 
for a three-month letter ballot. We hope to print the full text of the Draft Proposal in 
Pascal News when it becomes available so that readers will have a chance to provide 
comments on it to their own national standards group. 

The second resolution, passed unanimously by SC5, established a formal Working Group 
("Working Group 4, Pascal") to advise the British group on further standardization, and to 
consider proposals for such from bodies recognized by ISO. The Working Group is intended 
to replace the Experts Group, and will be under the Convenorship of Tony Addyman. Members 
are to be nominated by SC5 member bodies. This group will aid in resolving negative 
comments (if any) on the new Draft Proposal, and will probably coordinate future work on 
Pas cal ext ens ions . 

The SC5 meeting also saw an interesting exchange on the subject of Ada (the U.S. 
Department of Defense language). William A. Whitaker, attending as an observer from the 
United States, made a presentation to SC5 on Ada. Under questioning by the Australian 
representative (Arthur Sale), Whitaker admitted that Ada actually has little in common 
with Pascal. This stands in stark contrast to the impression one might get from reading 
DoD press releases and other articles which some feel have attempted to lend credence to 5 
the Ada project by associating it with Pascal. Thankfully, Pascal need no longer suffer ^ 
from such derogatory associations! zn 



(c) when the goto-statement occurs anywhere within a statement -sequence 
compound-statement or a rep eat -statement) of which S is a component statement; or 



(in 



(d) when the goto-statement occurs in a procedure or function declaration (within the 
scope of the label) nested in the block which declares the label (i.e., non-local goto's), 
and only if the statement prefixed by the label is not nested inside a structured 
statement (other than the compound-statement which is the statement part of the block). 

More than one member of the group certified that these restrictions can be enforced 
efficiently by a one-pass compiler with no run-time overhead. 

There was resistance to allowing jumps between "branches" of conditional-statements. It 
was argued that the use of such goto's is not good, is poor "style", and should not be 
part of the standard. After some discussion, the group agreed to further restrict the 
goto by not allowing the references cited in (b), above. As with most such changes, the 
precise redrafting was left to an individual member of the group. 

The major topic of discussion was conformant array parameters. This was confused by the 
fact that the form present in N510 had already been renounced by the British in favor of a 
form drafted by Arthur Sale. With the exception of a different proposal by Coen Bron, 
which was closer to the version in N510, there was nearly unanimous support for the 
version proposed by Arthur Sale. (See his note, below, for a description.) 

In addition to technical issues, the Experts Group also briefly reviewed Pascal standards 
activities within the nations represented. It was clear that the approach taken by BSI 
DPS/ 13/4 toward a Pascal standard had a great deal of support internationally, with the 
exception of a few technical details. Discussions are currently underway in attempting to 
resolve those issues not completed in Turin. 



In the United States 

Several small points should be noted as having changed since the Progress Report 
These changes occurred at the meeting of November 28.. 30 in Boston. 



in #15. 



First, a single joint committee has been formed from the ANSI-X3J9 and the IEEE Pascal 
Standards Committees. The new committee is formally called the "Joint ANSI/X3J9 - IEEE 
Pascal Standards Committee", abbreviated "JPC". 

Second, Jess Irwin has resigned as secretary of X3J9. Carol Sledge of On-Line Systems has 
volunteered to take the job. Correspondence with the JPC should be sent to: 

Carol Sledge (X3J9) 
c/o X3 Secretariat 
CBEMA: Suite 1200 
1828 L Street NW 
Washington, D.C. 20036 

Third, the proposed "SD-3" for considering extensions to Pascal printed in #15 (pages 
93.. 95) was modified to reflect the international interest in Pascal extensions which was 
apparent at the Turin meeting. The revised document specifies that the JPC will cooperate 
with Working Group 4 of SC5 on developing an international extended standard, and that the 
resulting American National Standard will be compatible. 

***************** 
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Implementation Notes 






Editorial 




COMMTTZD TO 5XOHJ.3NCS 



First, the formalities: 

Bob Dietrich 

MS 63-211 

Tektronix , Inc . 

P.O. Box 500 

Beaverton, Oregon 97077 

U.S.A. 



Tektronix, inc. 
P.O. Box 500 
Beaverton, Oregon 97077 



Phone: (503) 644-0161 
TWX: 910-467-8708 



phone: (503) 682-3411 ext 3018 



Feel free to call me (I'm usually in between 10AM and 5PM Pacific 
but consider yourself lucky if you find me near the phone. I don 
a secretary, and may have to be paged. Consider yourself foolhar 
you write me and expect a personal reply in less than a year. I 
to do better for those outside the U.S. Should you wish informati 
a specific implementation, please read Pascal News first. It's un 
that I will have any more current information than can be found 
Furthermore, this can put me in the delicate position of seem 
endorse a particular implementation, which I will not do for ethic 
legal reasons. These cautions aside, I'll do what I can to help. 
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Next, the traditional goals statement of a new editor. At this time, I 
don't plan to change anything (I know - every new editor and politician 
says the same thing). My basic goal is to publish a comprehensive list 
of Pascal implementations by the summer of 1980. Whether this will 
appear in one issue or several is yet to be discovered: a great deal 
depends on the cooperation of the readers of Pascal News. Which brings 
me to the next topic. 
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Coupon) . This amazing piece of paper is simply an implementation 
checklist with room to write on. Fill in the blanks, fold, and mail to 
the address on the back. Feel free to also send in camera ready 
checklists. I hope this will give us a little more to print in the 
meantime . 

Now for my biggest irritation. In my everyday work, I have used many 
different implementations/versions of Pascal. On our DECsystem-10 alone 
we have six different versions of Pascal available. This does not 
include some cross-compilers for other machines. Why do we have so many 
different compilers for the same machine? 

The reason we have so many versions still active is that many user 
programs have not been updated to account for major changes in new 
releases of the compilers, and so the old release stays around. Most of 
the changes have been non-trivial, and heavily impact whether the 
programs can be simply recompiled under the new release. The changes 
have included the way the character set, terminal I/O, I/O in general, 
operating system interface, et cetera, are mishandled. Even worse are 
the versions that made "improvements" to the language, such as: 

j := case k+34 of . . . 

And 

1 : = i_f FouledUp then sqr(x) else sqrt(z) 

Of course, the changes are rarely upward or cross compatible. 
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Please do not misunderstand me. I am not against extending Pascal 
(well, at least not totally against it). Some extensions make the 
bootstrap process for a new implementation much easier. What I am 
against is the effort put into extensions that would be much better 



directed toward fixing errors and implementing the full language. How I 
long for a full set of {ASCII} char! As a compiler writer, 1 realize 
that extending the language in a particular implementation both is fun 
and might help differentiate the product in the marketplace. This is 
especially true in the Pascal market, where both users and implementors 
have not really understood the language. 

What I am really looking for (I don't think I'm alone) is quality in the 
tools I use. Just as I wouldn't be too happy buying a saw missing half 
its teeth, or with half the teeth backwards, or with teeth on the handle 
where my hand is supposed to go, I really dislike the so-called 
implementations of Pascal whose manuals list ten major omissions to the 
language and thirty "improvements". The omissions are even less 
tolerable once an implementation has gotten past the "well, at least it 
looks like Pascal" stage. This is not quality. 
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A good many implementors are professional enough to assume this 
responsibility for quality, and have probably already done so. What of 
those individuals and companies who have not? What can we users do? 
Well, the best approach is to convince the implementor that conforming 
to standard Pascal is in the implementor ' s own best interests. The 
reasons can be many: good will, conditions of purchase, additional 
sales, blackmail, advertising, even legal requirements. In many 
countries, adoption of a standard (such as ISO Pascal) gives it the 
weight of law. Any product purporting to be Pascal in such a country 
MUST conform to the standard. 



It is fortunate that there are now two tools to back up this demand for 
quality. The first, of course, is the upcoming ISO Pascal standard. 
There are admittedly problems because the standard is not yet official, 
but at the same time the standard is for the most part not all that 
different from the Jensen and Wirth Report. Getting most 
implementations to conform to the Report would be a major accomplishment 



in itself, and not that far from where the 
end up . 



ISO standard will probably 



The second tool to help quality is the Pascal Validation Suite that was 
published in issue # 16. The biggest problem in quality assurance is 
finding quality tests, and the validation suite goes a long way toward 
solving this problem. It is also a very big advantage to have the suite 
available now, even before the Pascal standard is adopted. Implementors 
of other language standards had to wait quite a while (many are still 
waiting) before such a measurement device was available. I will have 
quite a bit more confidence in a particular implementation of Pascal if 
I know the results of having it try to process the validation suite. 

I would like to encourage both users and implementors to use the 
validation suite and send the results to me as well as to Arthur Sale. 
By all means, also send a copy to the implementor. I will then publish 
the reports I receive in Pascal News for the world to see. Please see 
the sample reports in issue # 16 for format. I would hope that over the 
next year we can get reports for each and every implementation (then 
again, I always have been an optimist). The letter campaign to 
implementors will also be requesting reports of the validation suite 
results . 

One last comment. Be kind to your implementor, especially if he is 
doing a good job. It's not all that easy to wrestle many of our poorly 
designed machines into speaking Pascal. Don't use the validation suite 
to beat him senseless, but have some patience. On the other hand, if he 
has implemented something that cannot even pass for a subset of Pascal, 
cannot add two numbers correctly, and has a lot of "improvements", be 
merciless . 



Implementation Critiques 

Digital Equipment PDP-11 ('Swedish') 



1979 December 19 



A critique of the Swedish Pascal compiler 

(as derived from its User Manual by A.H.J. Sale) 



1. The User Manual is a supplement to Jensen & Wirth. It is well-written, 
and describes the implementation of Seved Torstendahl running on FDP-lls 
under RSX-11M and IAS. 
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2. The manual first describes how to run Pascal programs under the operating 
systems, how to attach files, etc. 

3. The next section addresses extensions. The tokens are extended by: 
treasonable, given poor print capability 
J and use of these ISO positions for Swedish chars, 
l-not extension ; allowed by standard. 

f These three extensions are simply undesirable;, 
especially since neither # nor ! capture 
any of the meaning of the well-defined tokens. 
I recommend the removal of the last three extensions as being contrary 
to the best interests of portability of programs and programming skills, 
and ugly as well. 

4. The document introduces extra pre-defined constants: MAXINT, MININT, 
ALFALENG, MAXREAL, MINREAL, and SMALLREAL. It mis-calls these 
'standard' constants which they are not, except for MAXINT. No problems 
with the introduction of extra constants provided they are properly 
identified. 

5. 'Standard' types is also misused. TEXT is indeed standard and need not 
be in a section on extensions, but types 

ASCII = CHR(O) . .CHR(127) ; BYTE = CHR(O) . .CHR(255) ; 
are simply extra pre-defined types. This misuse of 'standard' runs throughout 
the document. Something can only be called 'standard' if it conforms to 
a standard, either the old de facto standard of Jensen & Wirth, or 
preferably the new ISO draft standard. We may as well get this right now . 
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6. The extended case statement (otherwise clause) does not use the syntax 
more or less agreed internationally and published in Pascal News, but 
uses an OTHERS label. The syntax suggests it need not be last. 

7. A LOOP-END construct is introduced, together with an EXIT. I strongly 
recommend the removal of this construct which is a frequent cause of error 
in many programs. Why it was introduced is difficult to understand since 
Pascal handles the so-called loop-and-a-half structure much better without 
it. 

8. There are 'Standard' procedures DATE and TIME; it seems a pity tnat these 
cannot be guaranteed to relate to the same instant, and that a single 
TIMESTAMP cannot return both values guaranteed synchronous. NEW is 
implemented, but not DISPOSE; MARK and RELEASE are provided. 

There is a HALT, and RESET and REWRITE allow file selection by additional 
parameters. BREAK flushes line buffers for the special file TTY, and 
acts as WRITELN for other text-files (irregular). PAGE inserts a form- 
feed character into the text-file. 

Random access is provided by allowing another integer parameter to GET and 
PUT. I cannot understand why people prefer to overload names with new 
meaning and introduce irregularity in preference to choosing new names 
such as PUTR and GETR. Especially since the axioms of GET/PUT do not hold. 

9. There are additional 'standard' functions RUNTIME, TWOPOW, SPLITREAL 
and IORESULT. 

10. There is an adjustable array parameter feature. How it works is a mystery 
as the component-type is apparently not given. The following example 

is taken from the manual: 

PROCEDURE MATADD(VAR A,B,C: ARRAY [INTEGER, INTEGER] ) ; 
It would seem highly desirable to alter this implementation to something 
with more abstract structure, and more checkable. 

11. There is also a facility to declare a new kind of parameter 

PROCEDURE -PRINT (STRING S) ; 
This feature turns Pascal's ordering on its head (type precedes identifier) 
and it misuses the word 'string' by defining it to be an array.' The 
facility is badly expressed, and should be described in terms of a sequence 
(= file) of characters. 



12. There is a facility to pass procedural and functional parameters, but 
it differs from the draft ISO standard in defining a new form of 
parameter-list. Congruity of two parameter lists is not adequately 
defined, but this is an informal document. 

13. There is an external compilation facility; the directive EXTERN is used 
followed by a parameter list. Examples 

EXTERN (FORTRAN) 
or EXTERN (FORTRAN,' TEST') 

14. The reserved word list is extended by LOOP, EXIT, OTHERS, EXTERN. 
If the loop construct is removed this drops to two. 

15. PACK and UNPACK are not implemented; only char and Boolean arrays 
are packed. (Presumably no records are packed, which is very 
unsatisfactory for many mini and micro applications.) 

16. Only local GOTOs are permitted; a set may have up to 64 elements; 
files may only be declared in the main program. 

17. The documentation cheats on MAXINT by disallowing it as a limit in a 
for-loop. It would be accurate to say that MAXINT in this implementation 
is really 32766, and that the constant called MAXINT should be renamed, 
perhaps to BIGINT or similar. Or the implementation should be improved 
(see Pascal News 15) . 

18. Set of char is allowed, by defining the type char to be the subrange 
of characters from CHR(32) . .CHR(95) . Of course this violates a lot of 
Pascal axioms, notably about the type of the result of CHR. A very crude 
approach to the problem. It should be done right. 



{ See Zilog Z-80 (Digital Marketing) ) 

{ See Zilog Z-80 (MetaTech) ) 

( See GOLEM B (Weizmann) ) 

This compiler runs under CP/M and produces macro-assembler code. The 
price is $275. 

Ithaca Intersystems (formerly Ithaca Audio) 
1650 Hanshaw Road 
P.O. Box 91 
Ithaca, NY 14850 

This compiler runs under CP/M and is a Pascal -P descendant. The price 
is $350. 

Digital Marketing 

2670 Cherry Lane 

Walnut Creek, Cft 994596 

This is a compiler for a cassette-based system, and sells for $35. 

Dynasoft Systems 

POB 51 

Windsor Junction, North Saskatchewan B0N 2V0 

Canada 

The information on this compiler is unclear. It appears to be all or 
partly in ROM, and sells for ^40. 

The Golden River Co., Ltd. 

Telford Road. 

Bicester, Oxfordshire 0X6 0UL 

England 
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Validation Suite Reports 




The University of Tasmania 

Postal Address: Box 252C, G.P.O., Hobart, Tasmania, Australia 7001 
Telephone: 23 0561. Cables Tasuni' Telex: 58150 UNTAS 



IN REPLY PLEASE QUOTE: 

FILE NO. 

IF TELEPHONING OR CALLING 

ASK FOR 



4th December, 1979 



Mr. R. Shaw, 

Digital Equipment Corp. , 

5775 Peachtree-Dunwoody Road, 

Atlanta, Georgia 30342 

U.S.A. 



Dear Rick, 



Enclosed is a copy of a report of the Pascal Validation Suite on a 
VAX-II Pascal system. The report was produced for us by Les Cooper at 
La Trobe University. 

The Pascal system is a Field Test version and is not available generally 
at this stage. All errors have been reported back to DEC who presumably will 
fix them before the system is finally released. The report should be seen 
in this context. Nevertheless, it provides an insight into what the VAX 
compiler will be like when it is officially released early in 1980. 

Les Cooper says he will provide an up-to-date copy of the report after 
the compiler has been officially released. 



Yours sincerely, 



u- 



Roy A. Freak, 

Information Science Department 



Digital Equipment VAX 11/780 (DEC) 



VAX- 1 1 Pascal - Tested At LaTrobe University 
Pascal Validation Suite Report 



Pascal Processor Identification 



Computer: 
Processor: 



Digital Equipment Corporation VAX-1 1/780 
VAX-11 Pascal Field Test version TO. 1-68 



Test Conditions 



Les Cooper 
Computer Centre 
La Trobe University- 
Australia 



Date: 
Version 



November 1979 
Validation Suite 2.2 



Conformance Tests 



Number of Tests. Passed: 128 
Number of Tests Failed: 9 



Details of Failed Tests 



Test 6.4.3.3-1 failed because an empty record contain- 
ing a semi-colon produces a syntax error. 
Test 6.3.3.3-4 failed because an attempt to redefine a 
tag field else\7here in the declaration part produces 
syntax errors. 

Test 6.4.3.5-1 failed because an attempt define a file 
of pointertype failed to compile. 

Test 6.5.1-1 failed because an attempt to define a file 
of filetype failed to compile. 

Tests 6.6.3.1-5, 6.6.3.4-2 failed to compile where they 
tried to pass a procedure with a formal parameter list 
as as formal parameter to another procedure. 
Test 6.9.4-15 shows that a write which does not specify 
the file does not write on the default file after 
reset (output) . 

Deviance Tests 



Dumber of Deviations Correctly Detected: 61 
Dumber of tests showing true extensions: 4 
Number of tests not detecting erroneous deviations: 

Number of tests failed: 5 



18 



may be usexl 



Details of Extensions 

Test 6.1.5-6 shows that lower case e 

numbers. 

Tests 6.8.3.9-9, 6.8.3.9-13, 6.8.3.9-14 show that the 

following may be used as the controlled variable in a 

for statement: intermediate non-local variable, formal 

parameter, global variable. 

Details .of Deviations not Detected 



Test 6.1.2-1 shows that nil may be redefined. 
Tests 6.2.2-4, 6.3-6, 6.4.1-3 show that a common 
error was not detected by the compiler. 



scope 



Tests 6.4.5-2, 6.4.5-3, 6.4.5-4, 6.4.5-5 indicate that 
type compatibility is used with var parameter elements 
rather than enforcing identical types. 

Test 6.6.2-5 shows the compiler permits a function de- 
claration with no assignment to the function identif- 
ier* 

Tests 6.8.2.4-2, 6.8.2.4-3, 6.8.2.4-4 show that a goto 
between branches of a statement is permitted. 
Tests 6.8.3.9-2, 6.8.3.9-3, 6.8.3.9-4, 6.8.3.9-16 show 
that assignment to a for statement control variable is 
not detected. 

Test 6.9.4-9 shows that zero and negative filed widths 
are allowed in write. 

Details of Failed Tests 



Test 6.6.3.6-2, 6.6.3.6-3, 6.6.3.6-4, 6.6.3.6-5 check 
the compatibility of parameter lists. They fail to 
compile where they use a procedure with a formal param- 
eter list as a parameter to another procedure. Test 
6.8.3.9-19 shows that insecurities have been introduced 
into for statements by allowing non-local control vari- 
ables . 



Error Han dling 



Number of Errors correctly detected: 
Number of errors not detected: 33 



14 



Details of errors not detected 



Tests 6.8.3.9-5, 6.8.3.9-6, 6.2.1-7 indicates that un- 
defined values are not detected. 

Tests 6.4.3.3-5, 6.4.3.3-6, 6.4.3.3-7, 6.4.3.3-8 indi- 
cate that no checking is performed on the tag filed of 
variant records. 

An assignment to an empty record is not detected in 
test 6.4.3.3-12. 

Tests 6.4.6-4, 6.4.6-5, 6.4.6-6, 6.4.6-7, 6.4.6-8, 
6.5.3.2-1, 6.8.3.5-5, 6.8.3.5-6, 6.6.6.4-4, 6.6.6.4-5, 
6.6.6.4-7 indicate that no bounds checking is performed 
on array subscripts, subranges, set operations, or case 

selectors. Note: The system default is run time 
checks off. If the tests had been compiled with checks 
on then the checking would have been done. 
Tests 6.5.4-1 and 6.5.4-2 show that a poor error mes- 
sage is given when a nil pointer is dereferenced and 
when an undefined pointer is dereferenced. 
Test 6.6.2-6 shows that, if there is no result assigned 
to a function, there is no run time error message. 
Test 6.6.5.6-6, 6.6.5.6-7 show that it is possible to 
change the current file position while the buffer vari- 
able is an actual parameter to a procedure and whilst 
the buffer variable is an. element of the record vari-* 
able list of a with statement. 

Test 6.6.5.3-3, 6.6.5.3-4, 6.6.5.3-5, 6.6.5.3-6 show 
that there is no errormessage when the following occur 
as the pointer parameter of dispose: nil, undefined 
pointer, variable which is currently an actual parame- 
ter, variable which is an element of the record vari- 
able list of a with statement. 

Test 6.6.5.3-7, 6.6.5.3-8, 6.6.5.3-9 fail because no 
checks are inserted to check pointers after they have 



been assigned a value vising the variant form of new. 
Test 6.8.3.9-17 show that two nested for statements nay 
ahve the same controlled variable. 



Implementation Defined 

Number of tests correctly run: 9 

Number of tests incorrectly handled: 

Details of implementation dependence 

Test 6.4.2.2-7 shows maxint to be 21474 883647 
Test 6.4.3.4-2 shows that a set of char is permitted. 
Test 6.4.3.4-4 shows that there are 255 elements in a 
set. 

Tests 6.7.2.3-2 and 6.7.2.3-3 show that Boolean expres- 
sions are fully evaluated. 

Tests 6.8.2.2-1 and 6.1.2.2-2 show that the variable is 
selected before the expression is evaluated in an as- 
signment statement. 

Test 6.10-2 shows that a rewrite is allowed on file 
output. 

Test 6.11-1 shows that alternate comment delimiters are 
implemented. 

Tests 6.11-2, 6.11-3 shov-; that equivalent symbol cannot 
be used for the standard reference representation for 
the up arrow, :, ;, :=, [, J, and the arithmetic opera- 
tors. 

Test 6.9.4-5 shows that two digits are written in an 
exponent. 

Test 6.9.4-11 shows the default field width to be in- 
teger 10, Boolean 16, real 16. 

Quality Measurement 

Number of tests run: 2 3 

Number of tests incorrectly handled: 

•Results of tests 

Test 5.2.2-1 shows that identifiers are not distingu- 
ished over their whole lengtlj. 

Test 6.1.3-3 shows that there are 15 significant char- 
acters in an identifier. 

Test 6,1.8-4 shows that no warning is given if a { or ; 
is detected in a comment. 

Tests 6.2.1-8, 6.2.1-9, and 6.5.1-2 indicate that large 
lists of declarations may be used in each block. 
Test 6.4.3.2-4 indicates that integer indextype is not 
permitted. 

Test 6.4.3.3-9 show that variant fields of a record oc- 
cupy the same space, using the declared order. 
Test 6.4.3.4-5 (Warshall's algorithm) took 1.010 CPU 
seconds and 249 bytes on the VAX-1 1/780. Note: This 
was using the VAX default of no run time checking. 
Test 6.8.3.5-2 shows that no warning is given for im- 
possible cases in a case statement. 

Test 6.8.3,5-8 shows that a large populated case is ac- 
cepted. 

Test 6.8.3.9-18 shows that the undefined value of a for 
statement controlled variable is left in the range of 
its type. 

Tests 6.8.3.9-20, 6.8.3.10-7 show that at least 15 lev- 
els of nesting are allowed when dealing with for stat- 
ments, with statements, and procedures. 



Test 6.9.4-10 shows that the output buffer 
at end of job. 



flushed 



Extensions 

Number of tests run: 



1 



Test 6.8.3.5-14 shows that otherwise is- implemented 
though -not with the same syntax as that adopted at the 
UCSD Pascal workshop in July 1978. 



VAX-1 1/7 80 Pascal - Commentary on Results 



The Validation suite has shown up quite a number of flaws in 
the compiler, as documented in the preceeding report. Of 
particular concern is the apparent philosophy that the run 
time checking should be off by default. 

These tests were run using Field Test version TO. 1-6 8 of the 
compiler. With luck (a lot) , the problems found will all be 
fixed before the compiler is released. 

DEC has been informed of the results of all the tests. They 
have been given run listings, etc. where necessary. The 
replies they send to me (when they arrive) will be included 
in this section of the report. 



PASCAL VALIDATION SUITE REPORT 



Pascal Txoccssox ldenti{ication 

Computex: Apple 11 

Vxocessox: UCSV Pascal vexAion 11.1 

TeAt Conditions 



TeSteX: R.A. Vxeak 

Vote: 3a.nu.asiy 19 80 

Validation Suite Vexsion: 2.2 



Con{onmance Test!> 
Humbex o{ tests passed: 
Numb ex o{ tests {ailed: 



116 
22 [13 basic causes) 



"Detail s o{ {ailed tests 

Test 6.1.2-3 shows that identi{ieXA and nesexved wonds 
an.li not distinguished conxectly oven thein whole length. 

Test 6.2.1-1 pH.oduLQ.2A an exxox in scope. 

Tests 6.4.3t3-1, 6.4.3.3-3 and 6.8.2.1-1 {ail because, 
empty {ield lists on. empty neconds axe not allowed. 

Test 6.4.3.3-4 indicates that a tag {ield de{inition 
iA not to cat to the xecoxd de{initijon. 

TestA 6.4.3.5-1 and 6.5.1-1 {ail because a {He o{ 
pointexs is not permitted, non can a {He be pant o{ 
a xecoxd stxuctuxe. 

Tests 6.6.3.1-5, 6.6.3.4-1, 6.6.3.4-2 and 6.6.3.5-1 
{ait because, the passing o{ pn.ocedan.eA I '{unctions as 
paxametenA hah not been implemented. 

TestA 6.6.5.2-3 and 6.6.5.2-5 {ail became eo{ is not 
set on an empty {He, non, iA it set a{tex a xewxite. 

TeAt 6.6.5.3-2 {ailA because dispose has not been 
implemented. 

TeAt 6.6.5.4-1 {ails because the. pnoceduxes pack and unpack 
have not been implemented. 

TeAt 6 A. 2. 4-1 {ails because non-local goto* axe not 
permitted. 

TeAt 6. S. 3. 5-4 {ailA becauAe a spaxse caAe statement wHl 
not compHe. [Thexe iA a limit on the s-cze o{ each pxoceduxc) . 



TeAt 6.8.3.9-1 {ails be.ca.a6e the assignment to a {on 
statement control vaniable {allows the evaluation o{ the 
{iXAt expxession. Use o{ extxeme values in a {on state- 
ment pnoduceA an infinite, loop [tcAt 6.8. 3.9-1) . 

TestA 6.9.4-4 and 6.9.4-7 {aH becauAe the. wniting o{ 
Heal valueA does not con{onm to the standaxd and the 
wniting o{ boolean valueA iA not permitted. 



Deviance Tests 

bSumbex o{ deviations conxectly detected: 56 

Humben o{ tests showing tnae extensions: 7 [4 actual extensions) 

Uunfoex o{ tests not detecting exxoneous deviations: 25 (12 basic causes) 

Humbex o{ testi> {ailed: 6 (2 basic causes) 



Details o{ extensions : 



Tests 6.1.7-6 and 6.4.5-11 show that stxings axe. allowed 
to have bounds othex than 1..n and that compatible stxings 
can have di{{enent numbenA o{ components . 

TestA 6.8.3.9-9 and 6.8.3.9-14 indicate that the {on- 
contnol vaxtable does not have to be local to tiie 
immediately enclosing block. 

TestA 6.10-1 and 6.10-3 show that {He paxametenA axe 
ignoxed and the pnede{ined identi{iex output may be xe- 
de{ined. 

Test 6. 10-4 shows that a pnogxam does not have to have a 
pnagxam statement. 



VetailA o{ deviations not detected: 



Test 6.1.2-1 shows that nil may be xede{ined. 

TestA 6.1.7-11 and 6.4.3.2-5 show that a null stxing iA 
accepted by the compilex and that stxings may have othex 
than a subnangc o{ integexs as bounds. 

Test 6.2.1-5 shows that an unsized label iA not detected. 

TestA 6.2.2-4 , 6.3-6 and 6.4.1-3 contain a common scope 
exxox which is not detected. 

Tests 6.3-5 and 6.7.2.2-9 show that the unaxy opexaton, + 
may be applied to non-axithmetic opexandA. 

Tests 6.4.5-2, 6.4.5-3, 6.4.5-4, 6.4.5-5 and 64.5-13 
show that identical compatibility iA not en{onced. 

TeAt 6.6.2-5 shows that a {unction without an assignment 
to the {unction vaxiable is not detected. 

TestA 6.6.6.3-4 and 6.6.6.4-6 show that xeal paxametenA 
axe allowed {on the {unction succ and pned, whHe txunc 
and xound can have integex paxametenA. 



Tests 6.8,2.4-2 and 6. 8. 2.4-3 show that a goto between 
branches oj a statement is permXtt.ed. 

Tests 6. $.3. 9-2 and 6. 8. 3. 9-3, 6.8.3.9-4 .and 6.8.3.9-16 
show that a lon,-dontA.ol variable may be altered in the 
range oj the jor statement. 

Test 6.8.3.9-19 shows that nested {on. statements using 
the. same control variable, are not detected. 

Tut 6.9.4-9 shows that integers may bo, written using a 
negative jormat. 



Details oj jolted tests : 



Tests 6.6.3.5-2, 6.6.3.6-2, 6.6.3.6-3, 6.6.3.6-4 and 
6.6.3.6-5 jolt because the. poshing oj procedures/ junctions 
as parameters has not been implemented. 

Test 6.8.2.4-4 jails because non-local gotos have not been 
implemented. 



Error handling : 

Numbejuctj errors correctly detected: 14 

Humbert oj errors not detected: 28 [14 basic causes) 

Number oj tests jailed: 4 (1 basic cause) 



Details oj erroxs not detected : 



Test 6.2.1-7 shorn that variables axe initialized to what 
was previously lejt in memory. 

Tests 6.4.3.3-5, 6.4.3.3-6, 6.4.3.3-7 and 6.4.3.3-8 indicate 
that no checking is perjormed on the tag jield oj vaxbant 
records . 

An assignment to an emptu record Is not detected in test 
6,4.3.3-12. 

Tests 6.4.6-7, 6.4.6-8 and 6.7.2.4-1 indicate that no 
bounds checking is perjormed on set operations and over- 
lapping sets are not detected. 

Tuts 6.5.4-1 and 6.5.4-2 show that a nit pointer or an 
uninitialized pointer are not detected bejore use. 

Test 6.6.2-6 shows that a junction without an assignment 
to the junction variable id not detected. 

Test 6.6.5.2-1 shows that a put on an input jite is not 
detected. 

Test 6.6.5.2-2 shows that a get past eoj is not detected. 

Test 6.6.5.2-7 indicates that a jile bujjer variable can 
be altered illegally. 



Tests 6.6.5.3-7, 6.6.5.3-8 and 6.6.5.3-9 jail because no 
checks are inserted to check pointers ajter they have been 
assigned a value using the variant jorm oj new. 

Tests 6.6.6.4-4, 6.6.6.4-5 and 6.6.6.4-7 indicate that no 
bounds checking is perjormed on the junctions succ, pred 
or chx. 

Tests 6.7.2.2-6 and 6.7.2.2-7 show that integer overjlow 
and under jlow conditions are not detected. 

Testi> 6.8.3.5-5 and 6.8.3.5-6 show that ij the value oj 
the case index does not correspond to a cas : e\label, control 
passes to the statement ajter the case statement. The 
error is not detected. 

Tests 6.8.3.9-5, 6.8.3.9-6 and 6.8.3.9-17 show that a jor 
control variable may be used ajter the jor loop has 
terminated. Nested jor loops using the same control 
variable are not detected. 



Details oj jailed tests : 



TesU 6.6.5.3-3, 6.6.5.3-4, 6.6.5.3-5 and 6.6.5.3-6 jail 
because dispose lias not been implemented. 



Jmplementatio ndejined 

Numb o. x oj tests run: 15 

Number oj tests incorrectly handled: 



Details oj implementation- dejinition: 



Test 6.4.2.2-7 shows maxivit to be 32767. 

Tests 6.4.3.4-1 and 6.4.3.4-4 show that large sets are 
accepted by the compiler but. a run-time limit oj 512 elements 
is imposed. A set oj char is allowed. 

Test 6.6.6.1-1 shows that no standard procedures or junctions 
may be passed as parameters. 

Test 6.6.6.2-11 gives some details oj real number jormdti> 
and machine characteristics. 

Tests 6.7.2.3-2 and 6.7.2.3-3 show that boolean expressions 
are jully evaluated. 

TesU 6.8.2.2-1 and 6.8.2.2-2 show that a variable is 
selected bejore the expression is evaluated in an assignment 
statement. 

Tests 6.9.4-5 and 6.9.4-11 show that the number oj digits 
in an exponent, jield varies according to the size oj the 
exponent. The dejault output jield width jor integers and 
reals oJUso varies according to the size oj the expression 
printed. 



TeAt 6.10-2 Indlcatts that a newnitt cannot be pen^onmtd 
on tht JStandand ^IZt, output. 

TeAtA 6. 11-1 , 6.11-2 and 6.11-3 Ahow that the. alttnnatlvt 
comment dttimiteAA have, bttn impltmtnttd but no otheA 
tquu.vcile.nt. symbols have bttn tmpZemtnttd. 



DttaiZs oj jaiZtd teAtA: 



TeAt 6.8.3.5-8 lolls - a Zonae cost statement cauAts tht 
blzt o& the pKoceAuKt to ovtn^low tht maximum Limit. 



QuaJUXy IhtaAanemtnt 

Uumbex oi teAtA nun: 22 

Humbtn o£ teAtA InconntctZy handZtd: 1 



ExttnAlonA 

Uumbtn o^ teAtA nun: 1 



RtAultA oj teAtA '. 



TeAtA 5.2.2-1 and 6.1.3-3 Ahow that IdtntlfiltnA ant dlAtlng- 
uAAhtd oven thtlt falnAt ttght chanactejvs onZy. 

TeAt 6.1.S-4 IndinateA that no heZp Zs pnovlded ion dtttct- 
tng uncZoAtd tommtntA. 

TeAtA 6.2.1 -8 and 6.2.1-9 Indicate that mont than SO typts 
may bt compiled and mont than SO ZabeZA may bt dtclantd 
and AiXtd. TeAt 6.5.7-2 Ahow* a limit o£ 70 ldtnti{lojiA 
In a ZUt haA bten impoAtd. 

TeAt 6.4.3.2-4 a horn that an annay with an Inttgtn Indtx- 
typt Is not ptnmijtttd. 

TeAt 6.4.3.3-9 Ahows that vanlant fields oh a ntcnod ast 
nevtnAt tonneZation fan 6 to nag t. 

TeAt 6.4.3.4-5 [WaJiAkaZl't oXgonithm) took 166 byteA ok todt. 
Ho timing .infionmatlcn iA avaiZablt. 

TeAt 6.6.1-7 A horn that pnoctdaneA may bt neAttd to a dtpth 
oh 7 . Ton Atattmtnts may bt neAttd to a dtpth. gntattn'than 
IS [teAt 6.8.3.9-20) but with AtattmtntA may bt neAttd to 
a dtpth oi 11 [teAt 6.8.3.10-7). 

TeAtA 6.6.6.2-6, 6.6.6.2-7, 6.6.62-8, 6 6.6.2-9 and 6.6.6.2-10 
teAttd tht hqnt, atan, txp, Ain/co-S and In ^unctionA and 
aZZ teAti, went tompltttd AucctAi> iuZly . {Tht teAtA had to 
bt modl^ltd to avoid tht limit plated on pnotedunt Alzt) . 

TeAt 6.7.2.2-4 AhowA that division Into ntgotlvt optnandA 
Is IntonAlAttnt but dlviAlon by ntgatlvt optnandA Ia conAls- 
ttn. Tht quotient iA tnunc (A/B) fan all optnandA. mod[a,b) 
ZieA In (0,6-7) . 

TeAt 6.8.3.5-2 AhowA that no wanning iA given fan a aaAt 
conAtant which cannot bt ntachtd. A 

TeAt 6.8.3.9-18 Ahow6 that no nangt chtckA ant InAtnttd on 
a Ion contnol vanlablt a^ttn a fan loop. 

TeAt 6.9.4-10 AhowA that tht iiZt, output, Is {luAhtd at 
tnd oq job and teAt 6.9.4-14 Ahows that ntcuAAlvt 1/0 uAlng 
tht JSamt £U£t Is allow td. 



TeAt 6.8.3.S-14 Ahows that tht qthtnwiAt clauAt In a cast 
Atattmtnt haA not bttn impZementtd. ~* ~ "* 



Pascal Validation Suite Report 



Pascal processor identification 

This Pascal-VU compiler produces code for an EM-1 machine as de- 
fined in C1D. It is up to the implementor of the EM-1 machine 
whether errors like integer overflow, undefined operand and range 
bound error are recognized or not. Therefore it depends on the 
EM-1 machine implementation whether these errors are recognized in 
Pascal programs or not- The validation suite results of all known 
implementations are given- 
There does not (yet) exist a hardware EM-1 machine. Therefore, 
EM-1 programs must be interpreted, or translated into instructions 
for a target machine. The following implementations currently ex- 
ist: 

Implementation 1: an interpreter running on a PDP-11 (using 
UNIX). The normal mode of operation for this interpreter is 
to check for undefined integers, overflow, range errors etc. 

Implementation 2: a translator into PDP-11 instructions (using 
UNIX). Less checks are performed than in the interpreter, be- 
cause the translator is intended to speed up the execution of 
well-debugged programs- 



Test 6.6.5.3-3: 

T£St Sev^ratpointer type dennitions Crekord) referring to 
the same record type are incompatible. 

Test 6.6.3.4-2: 

Only a single procedure identifier is allowed in a formal 
procedure parameter section. 

Test 6.9.4-4: 

Reals printed in scientific notation always contains an 
exponent part, even for exponent equal to zero. 

Latest standard proposal 

A newer version of the proposal is received in November 1979. 
Because of the differences between these versions the follow- 
ing tests are changed: 

Test 6.1.5-6: 

The case of any letter occurring anywhere outside of a 
character-string shall be insignificant in that oc- 
currence to the meaning of the program. 

Test 6.4.3.3-3: 
Test 6.4.3.3-11: 
Test 6.4.3.3-12: 

Definition of an empty record is not allowed. 

Test 6.4.3.3-10: 

The case-constants introducing the variants shall be of 
ordinal-type that is compatible with the tag-type. 

Test 6.5.1-1: 

The type of the component of a file-type shall be neither 
a file-type nor a structured-type with a file component. 

Test 6.9.4-4: 

Test 6.9.4-5: 

The character indicating the exponent part of a real as 
written in scientific notation is either 'e' or 'E'. 

Test 6.9.4-4: 

The representation of a positive real in fixed point for- 
mat does not include a space if it does not fit in the 
specified field width. 

Test 6.9.4-7: 

The case of each of the characters written as representa- 
tion for a Boolean is implementation-defined. 

Test 6.9.4-9: 

Zero or negative field width is allowed in write- 
parameters. 
Conformance tests 

Number of tests passed = 138 
Number of tests failed = 1 

Details of failed tests 



Test 6.1.2-3: 



Character sequences starting with the 8 characters 'pro- 
cedur' or 'function' are erroneously classify as the 
,i.c^ni<: 'nrocedure' and 'function . 



word-symbols 'procedure' and 



Test Conditions 

Tester: J wW. Stevenson 

Date: December 19, 1979 

Validation Suite version: 2.0, dated June 19, 1979 

The final test run is made with a sligh:ly modified validation 
suite. The changes made can be divided into the following 
categories: 

Typing errors 



Test 6.4.3.5-1: 

the identifier 'ptrtoi' must be a type-identifier, not a 
variable-identifier. 

Test 6.6.3.3-1: 

The type of 'colone* should probably be 'subrange', not 
'colour', because the types of actual and formal variable 
parameters should be identical. 

Test 6.6.3.1-5: 

In passing a procedure as actual parameter the parameters 
must not be specified. So line 29 must be changed to 
conform(alsoconforms) 

Test 6.6.5.3-1: 

This test is incorrectly terminated by 'END.' instead of 
•end.'. 

Test 6.6.1-7: 

The terminating 'end.' is incorrectly preceded by a 
space. 

Test 6.9.4-14: 

The program parameter 'f must be removed. 

Portability p rob lens 



Test 6.6.3.1-2: 

A set of integer subrange containing more than 16 ele- 
ments may give problems for some implementations. A spe- 
cial option must be provided to the Pascal-VU compiler, 
specifying the number of elements. 

Test 6.6.6.2-3: 

Not all implementations support reals with 9 decimals of 
precision. The precision supported by Pascal-VU is about 
7 decimals (24 bits). 

Erroneous programs 

Some tests did not conform to the standard proposal of Febru- 
ary 1^ 79. It is this version of the standard proposal that is 
used by the authors of the validation suite. 

Test 6.3-1: 

Test 6.6.5.1-4: 

Test 6.4.5-5: 

The meaning of these test program is altered by the trun- 
cation of their identifiers to eight characters. 



Test 6.4.3.3-1: 

A record definition consisting of a single semicolon is 
illegal . 



Deviance tests 

Number of deviations correctly detected = 81 
Number of tests not detecting deviations = 12 

Details of deviations 

The following tests fail because the Pascal-VU compiler only 
generates a warning that does not prevent to run the tests- 
Test 6.2.1-5: 

A declared label that is never defined produces a warn- 
ing. 

Test 6.6.2-5: 

A warning is produced if there is no assignment to a 
function-identifier. 

The following tests are compiled without any errors while they 
do not conform to the standard. 

Te ;t 6.2.2-4: 

Test 6.3-6: 

Test 6.4.1-3: 

Undetected scope error. The scope of an identifier should 
start at the beginning of the block in which it is de- 
clared. In the Pascal-VU compiler the scope starts just 
after the declaration, however. 

Test 6.8.2.4-2: 

Test 6.8.2.4-3: 

Test 6.3.2.4-4: 

The Pascal-VU Compiler does not restrict the places from 
where you may jump to a label by a gbto-statement . 

Test 6.8.3.9-2: 
Test 6.8.3.9-3: 

Test 6.8.3.9-4: 

Test 6.3.3.9-16: 

There are no errors produced for assignments to a vari- 
able in use as control-variable of a for-statement. 



Error handling 



The results depend on the EM-1 implementation. 

Number of errors correctly detected = 

Implementation 1: 26 

Implementation 2: 12 
Number of errors not detected = 

Implementation 1: 19 

Imp' mentation 2: 33 

Details of errors not detected 



Test 6.2.1-7: 

It is allowed to print all integer values, even the spe- 
cial 'undefined* value* 



Test 6.4.3.3-5: 
Test 6.4.3.3-6: 



Test 6.4.3.3-7: 

Test 6.4.3.3-8: 

The notion of 'current variant 1 is not 
even if a tagfield is present. 



implemented, not 



Test 6.4.6-4: 
Test 6.4.6-5: 

Implementation 2: 



Subrange bounds are not checked. 



Test 6.4.6-7: 

Test 6.4.6-8: 

Test 6.7.2.4-2: 

If the base-type of a set is a subrange, then the set 
elements are not checked against the bounds of the 
subrange. Only the host-type of this subrange-type is 
relevant for Pascal-VU. 

Test 6.5.3.2-1: 

Implementation 2: Array bounds are not checked. 

Test 6.5.4-1: 
Test 6.5.4-2: 

Implementation 2: Nil or undefined pointers are not 

detected. 



Test 6.6.2-6: 

An undefined function result is not 
is never used in an expression - 



etected, because it 



Test 6.6»5.2-6t 

Test 3.6.5. £~7; 

Changing the file position while the window is in use as 
actual variable parameter or as an element of the record 
variable list of a with-statement is not detected. 



Test 6.6»5.3~3t 

Tsst 6,6,5.3-4^ 

liaplestntattof! 2i disposing nil or an undefined 
i? f*ot detected* 



pointer 



Test 6.6.5.3-5: 
T*at 6.6.5,1-6: 

disposing 3 variable while it is in use as actual vari- 
able parameter or as an element of the record variable 
irst of a with-statement is not detected. 

Test 6.6.5*3-!?: 

Test 6,6,5.3-8: 

Te&t $.6.5.3-9: 

It is mrt detected that a record variable, created with 
the variant form of new, is used as an operand in an ex- 
pression or as the variable in an assignment or as an ac- 
tual value parameter. 



Test 6.6.6.4-4: 
Test 6.6.6.4-5: 
Test 6.6.6.4-7: 

Implementation 2: There are no 

succ and chr. 



range checks for pred, 



Test 6.7.2.2-3: 
Test 6.7.2.2-6: 
Test 6.7.2.2-7: 
Test 6.7.2.2-8: 

Implementation 2: Division by or 

not detected. 



integer overflow is 



Impleaentation dependence 

Number of test run =15 

Number of tests incorrectly handled = 

Details of impleaentation dependence 



Test 6.4.2.2-7: 

Haxint = 32767 

Test 6.4.3.4-2: 

'set of char* allowed. 

Test 6.4.3.4-4: 

Up to 256 elements in the range 0..255 in a set. 

Test 6.6.6.1-1: 

Standard procedures and functions are not allowed as 
parameter. 

Test 6.6.6.2-11: 

Details of the machine characteristics regarding real 
numbers. 



Test 6.7.2.3-2: 
Test 6.7.2.3-3: 

Boolean expressions fully evaluated. 

Test 6.8.2.2-1: 

Test 6.8.2.2-2: 

The expression in an assignment statement is evaluated 
before the variable selection if this involves pointer 
dereferencing or array indexing. 

Test 6.9.4-5: 

Number of digits for the exponent is 2. 

Test 6.9.4.11: 

The default field widths for integer. Boolean and real 
are 6, 5 and 13. 

Test 6.10-2: 

Rewrite(output) is a no-op. 

Test 6.11-1: 
Test 6.11-2: 
Test 6.11-3: 

Alternate comment delimiters implemented, but not the 

other equivalent symbols- 



Quality aeasurement 



Number of tests run = 23 

Number of tests incorrectly handled = 

Results of tests 



Test 5.2.2-1: 
Test 6.1.3-3: 

Only 3 characters are significant in identifiers. 



Both ';' and 'V cause a warning message if they are 

found inside comments- 
Test 6.2.1-8: 
Test 6.2.1-9: 

Large lists of declarations are possible in each block. 



3> 
CO 

3> 



Test 6.4.3.2-4: 

An ' arrayCinteger3 of is not allowed. 

Test 6.4.3.3-9: 

Variant fields of a record occupy the same space, using 
the declared order. 

Test 6.4.3.4-5: 

Size and speed of Warshall's algorithm depends on the im- 
plementation of EM-1 

Implementation 1: 
size: 81 bytes 
speed: 4.20 seconds 

Implementation 2: 

size: 204 bytes 
speed: 0.62 seconds 

Test 6.6.1.7: 

At least 15 levels of nested procedures allowed. 

Test 6.7.2.2-4: 

'div' is correctly implemented for negative operands. 

Test 6.8.3.5-2: 

The compiler requires case constants to be compatible 
with the case selector. 

Test 6:8.3.5-8: 

Large case statements are possible. 

Test 6.3.3.9-18: 

The value of the control variable of a normally terminat- 
ed for-statement is equal to the final value. 

Test 6.3.3.9-20: 

At least 20 nested for-statements allowed. 

Test 6.8.3.10-7: 

At least 15 nested with-statements allowed. 

Test 6.9.4-10: 

Line marker appended at end of job if the last character 
written is not a line marker. 

Test 6.9.4-14: 

Recursive i/o using the same file allowed. 



The following 5 tests test the mathematical functions. For 
each the following three quality measures are extracted from 
the test results: 



meanRE: mean relative error. 

maxRE: maximum relative error 

rmsRE: root-mean-square relative error 



Test 6.6.6-2-6: 

Test sqrt(x): no errors and correct results. 

TeSt Tet^arctanCx): may cause underflow or underflow errors. 
meanRE: 2 ** -30.46 
maxRE: 2 ** -22.80 
rmsRE: 2 ** -24.33 

TeSt Test 6 exp(x): may cause underflow or overflow errors. 
meanRE: 2 ** -25.37 
maxRE: 2 ** -17.62 
rmsRE: 2 ** -19.56 

Test 6.6.6.2-9: 

Test sin(x): may cause underflow errors. 

meanRE: 2 ** -22.98 

maxRE: 2 ** -10.43 

rmsRE: 2 ** -15.59 

Test cos(x): may cause underflow error?. 

meanRE: 2 ** -21.69 

maxRE: 2 ** - 8.23 

rmsRE: 2 ** -13.37 

Test 6.6.6.2-10: 

Test ln(x): no errors 

meanRE: 2 ** -25.12 
maxRE: 2 ** -21.97 
rmsRE: 2 ** -23.75 



Extensions 

Number of test run = 
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CDC- 6 000 RELEASE 3 



PASCAL VALIDATION SUITE REPORT 

Pascal Processor Identification 

Computer: Control Data Corp. CYBER 74, running NOS 1.3 

Processor: CDC-6000 Release 3 (Zurich Compiler) of January, 

1979 



Test Conditions 

Tester: 

Date: 



Rick L. Marcus 
January, 1980 



Validation Suite Version: 2.2 

Conformance Tests 

Number of tests passed: 128 

Number of tests failed: 11 



Details of failed tests 

Test 6.1 .8-3 is not relevant; only one form of comment 
is allowed. 

Test 6.2.2-3 fails because the compiler thinks that the 
scope of node = real covers procedure ouch. 

Test 6.2.2-8 fails because assignment to a function is 
allowed only within the function body. 

Test 6.4.3.3-1 fails because the declaration for an 

empty record (D) is not allowed. If the semi -colon is 

removed from the record definition then there is no 
error, which can be seen in the next test, 6.4.3.3-3 . 

Test 6.4.3.3-4 fails because the tag-field in a record 
may not redefine an existing type declared elsewhere. 

Test 6.5.1-1 fails because the compiler does not allow a 
file of record . .. where the record contains a file as a 
field. I believe the latest version of the standard 
changes this. Our compiler will pass the test if files 
of files are not allowed. 

Test 6.6.3.1-1 fails in procedure Testtwo because of 
'strict' type checking. Passing a variable of type 
colour as a parameter of type subrange causes the error. 
Passing as a value paramter is allowed(i.e. , procedure 
Testone passes the test). 

Test 6.8.3.5-4 fails because the range of case labels is 
too large. 



Test 6.9.1-1 fails because eoln is not necessarily true 
after the last character written on a line. The 
operating system pads to an" even number of characters on 
a line with blanks. 

Test 6.9.4-4 fails because the test assumes only two 
places in the exponent field while there are three on 
our CDC systems. 

Test 6.9.4-7 fails because Booleans are right justified 
on CDC 6000 Pascal, not left as in the test. I believe 
the latest standard assumes right justification, so that 
the compiler would pass the test in that case. 



Deviance Tests 

Number of deviations correctly detected: 7 6 

Number of tests not detecting erroneous deviations: 18 

Details of deviations 

Test 6.1.2-1 shows that nil is not a reserved word. 

Tests 6.1 .5-6 is not relevant as only upper case is 
allowed anywhere in a Pascal program. 

Test 6.2. 1-5 shows that a label may be declared without 
being used anywhere in a program. 

Tests 6.2.2-4 , 6.3-6 , 6.4.1-3 show that a common scope 
error was not detected by the compiler. 

Test 6.6.2-5 shows that a function need not be assigned 
a value inside its body. The value of A after the 
assignment ( A := ILLEGAL (A) ) is zero. 

Test 6.6 .3.5-2 shows that strict type compatibility of 
functions passed as parameters is not required. 

Tests 6.8.2.4-2 . 6.8.2.4-3 . 6.8.2.4-4 show that a goto 
between branches of a statement is permitted. 

Tests 6.8.3.9-2 , 6.8.3.9-3 , 6.8.3.9-4 , and 6.8.3.9-16 
show that an assignment may be made to a for statement 
control variable. 

Test 6.8.3.9-14 shows that a for loop control variable 
may be a variable global to the whole program. 

Test 6.8.3.9-19 shows that in nested for loops, if both 
have the same control variable, then the value gets 
changed by the inner loop and falls out of the outer 
loop after 1 iteration. 

Test 6.9.4-9 shows that characters may be written even 
if the field width is too small. 

Error Handling 

Number of errors correctly detected: 24 

Number of errors not detected: 21 

Number of tests incorrectly handled: 1 



Details of errors not detected 

Test 6.2.1-7 shows that the value of I is that which is 
left over from procedure q (1=3). 

Tests 6.4.3.3-5/6/7/8 indicate that no checking is done 
on the tag field of variant records. 

Test 6.4.3.3-12 shows that an empty record can be 
assigned an undefined empty value. 

Test 6.4.6-8 shows that strict type compatibility is not 
enforced for sets passed by value. 

Test 6.6.2-6 : The error was not detected. The value of 

the variable CIRCLEAREA was zero after the assignment. 

It seems that a function is assigned the value zero if 

no assignment is made in its body. 

Test 6.6.5.2-2 fails to catch the error because of 
system padding of blanks to an even number of blanks. 

Test 6.6.5.2-6/7 shows that I/O is not implemented 
according to the standard. 

Test 6.6.5.3-5 fails because no check is made by the 
runtime system to see if the variable being disposed of 
is a parameter to the procedure which calls dispose- 



Tests 6.6.5.3-6/7/8/9 all fail. 

Tests 6.7.2.2-6/7 fail because an integer variable does 
not cause an overflow error when it is over the value of 
i maxint. 

Tests 6.8.3.9-5/6 show that the value of an integer 
control variable is set to -576460752303423487 after the 
for loop. 

Test 6.8.3.9-17 shows that two nested for loops may have 
the same control variable. 

Details of tests incorrectly handled 

Test 6.6.6.3-3 : An overflow of the real variable reel 
caused termination of the program. 

Imp lement at iondef ined 

Number of tests run: 15 

Number of tests incorrectly handled: 

Deatails of implementation-dependence 

Test 6.4.2.2-7 shows maxint to be 281474976710655. 

Tests 6.4.3.4-2/4 show that set bounds must be positive, 
have no element whose ordinal is greater than 58, and 
that set of char is not legal. 

Test 6.6.6.1-1 indicates that standard procedures and 
functions are not allowed to be passed as parameters to 
procedures and functions. 



Test 6.6*6.2-11 details some machine characteristics 
regarding number formats. 

Tests 6.7.2.3.2/3 show Boolean expressions are fully 
evaluated. 

Tests 6.8.2.2-1/2 show that a variable is selected 
before an expression is evaluated in an assignment 
s tatement . 

Test 6.9.4-5 shows that the number of digits in an 
exponent is 3. 

Test 6.9.4-11 details the default field width specific- 
ations: 10 for integers and Booleans and 22 for reals. 

Test 6.10-2 shows that a rewrite is allowed on the file 
output, but that it has no effect (i.e., output is not 
rewritten) unless there is an actual local file of a 
different name which replaces output on the control 
statement to execute the program. 

Test 6.1 1-1/2/3 show that alternate comment delimiters 
and other alternate symbols have not been implemented. 



Quality 

Number of tests run: 23 

Number of tests incorrectly handled: 

Results of quality measurements 

Tests 5.2.2-1 and 6.1.3-3 show that identifiers are not 
distinguished over their whole length; only the first 10 
characters are significant. 

Test 6.1.8-4 shows that no warning is given if a valid 
statement or semicolon is embedded in a comment. 

Tests 6.2.1-8/9 and 6.5.1-2 indicate that large lists of 
declarations may be made in each block. 

Test 6.4.3.2-4 shows that an array with an indextype of 
INTEGER is not permitted. At this site the use of 
INTEGER for an indextype is permitted only in the 
current implementation of dynamic arrays. 

Test 6.4.3.3-9 shows that the variant fields of a record 
occupy the same space, using the declared order. 

Test 6.4.3.4-5 (Warshall's algorithm) took 0.236 seconds 
CPU time and 171 words (10260 bits) on the CDC CYBER 74. 

Test 6.6.1-7 shows that procedures cannot be nested to a 
level greater than 9. 

Tests 6.6.6.2-6/7/8/9/10 tested the sqrt, a tan, exp, 
sin/cos, and In functions and all tests showed there 
were no significant errors in their values. 

Test 6.7.2.2-4 shows that div and mod have been imple- 
mented consistently, mod returns the remainder of div . 

Test 6.8.3.5-2 shows that case constants do not have to 



be of the same type as the case index, if the case index 
is a subrange, but the constants must be compatible with 
the case index. 

Test 6.8.3.5-8 shows that a large case statement is 
permissible ( >256 selections ). 

Test 6.8.3.9-18 shows that the use of a control variable 
is allowed after the for loop. The run-time system 
catches the use of the control variable this time 
because after exiting the loop the variable is set to 
the value found in Test 6.8.3.5.9-5 . and the case 
variable is out of range. 

Tests 6.8.3.9-20 and 6.8.3.10-7 indicate that for and 
with statements may be nested to a depth greater than 

Test 6.9.4-10 shows that file buffers are flushed at the 
end of a the program. 

Test 6.9.4-14 indicates that recursive I/O is permitted, 
using the same file. 



Extension 

Number of tests run: 1 
Number of tests incorrectly handled: 
Details of extensions 



Test 6.8.3.5-14 shows that the 'OTHERWISE' clause has 
been implemented in a case statement. 



□ □ □ □ 



TI PASCAL 



Information is available 



0. DATE/VERSION 

Release 1.6.0*, January 1980. 

1 . IMPLEMENTOR/MAINTAINER/DISTRIBUTER 

Implemented by Texas Instruments, 
from TI sales offices, or write to 

Texas Instruments 

Digital Systems Group, MS784 

P. 0. Box 1444 

Houston, Texas 77001 

or call (512) 250-7305. Problems should be reported to 

Texas Instruments 
Software Sustaining, MS2188 
P. 0. Box 2909 
Austin, Texas 78769 

or call (512) 250-7407. 

2 . MACHINE 

The compiler runs on a TI 990/10 or 990/12. The compiled 
object code can be linked for execution on any member of the 990 
computer family. 

3. SYSTEM CONFIGURATION 

The compiler runs under the DX10 operating system (release 
3) and requires at least a TI DS990 Model 4 system, which 
includes a 990/10 with 128K bytes of memory and a 10 megabyte 
disk. (More than 128K of memory may be required, depending on 
the size of the operating system.) Compiled programs can be 
executed on any FS990 or DS990 system, using the TX5, TX990, or 
DX10 operating systems. 

4. DISTRIBUTION 

Available on magnetic tape or disk pack. Contact a TI 
salesman for a price quotation and further details. 

5. DOCUMENTATION 

Complete user-level documentation is given in the "TI Pascal 
User's Manual", TI part number 946290-9701. 



6. MAINTENANCE POLICY 

TI Pascal is a fully supported product. Bug reports are 
welcomed and maintainence and further development work are in 
progress. 

7 . STANDARD 

TI Pascal conforms to "standard" Pascal, with the following 
principal exceptions: 

* A GOTO cannot be used to jump out of a procedure. 

* The control variable of a FOR statement is local 

to the loop. 

* The precedance of Boolean operators has been 

modified to be the same as in Algol and Fortran. 

* The standard procedures GET and PUT have been 

replaced by generalized READ and WRITE 

procedures. 
TI Pascal has a number of extensions to standard Pascal, 
including random access files, dynamic arrays, ESCAPE and ASSERT 
statements, optional OTHERWISE clause on CASE statements, and 
formatted READ. 

8 . MEASUREMENTS 



The compiler occupies a 64K byte memory region, 
speeds are comparable to the 990 Fortran compiler. 



Compilation 



RELIABILITY 

The system has been used by several different groups within 
TI since October of 1977, and by a number of outside customers 
since May of 1978. Updates have been released in January 1979 
and January 1980. This long history of extensive use and 
maintainance makes this a reasonably stable and reliable 
product. 



10. 



DEVELOPMENT METHOD 



The compiler produces object code which is link-edited with 
run-time support routines to form a directly executable program. 
The compiler is written in Pascal and is self-compiling. 

11. LIBRARY SUPPORT 



TI Pascal supports separate compilation of routines and 
allows linking with routines written in Fortran or assembly 
language . 



Intel 8080/8085 /MettX Tecfr\ 



-0- Date : 

Version: 



Specializing In Innovative Information Processing 



Pascal/MT Implementation Specification 



November 3, 1979 
Release 2 - 5 



-1- Distributed, Implemented and Maintained by : 

MetaTech, 8672-1 Via Mallorca, La Jo 11a, Ca. 92037 
(714) 223-5566 x289 or (714) 455-6618 

-2- Machine : Intel 8080/8085 and Zilog Z80 

-3- System Configuration : 

•Pascal/MT operates under the CP/M operating system Cor and equivalent system such as CDOS , 
IMDOS, etc.) in a minimum of 32K bytes of memory. 

The package consists of a compiler and symbolic debugger and generates 8Q80/Z8Q object 
code directly from the Pascal program source. 

The symbolic debugging package is optionally copied into the output object file by the compiler. 

-4- Distribution: 

The Pascal/MT package is distributed on a single density 3-inch floppy diskette which contains: 

The compiler for Pascal/MT 

The symbolic debugging package 

The text for the compiler error messages 

Two utility programs written in Pascal/MT to illustrate the facilities of the language 

Cost of a single system license for Pascal/MT (.includes manual) is $99.95 

Manual available for $30.00 

Source for the run-time package is $50.00 

Master Charge, Visa, UPS COD, and Purchase Orders 

-5- Standard: 

Pascal/MT implements (in 2.5) a subset of the full Pascal language. This was done to generate 
both space and time- efficient code for 8-bit microcomputers. 

Pascal/MT also contains a number of "built-in" procedures. This allows source code using 
these procedures --to be'portable to ether systems providing appropriate routines are implemented 
on the other systems . 

Pascal/MT omits the following features from the Pascal standard (Jensen & Wirth 2nd Ed.): 

*No LABEL declaration and therefore no GOTOs 
Non-standard file support for CP/M files 

♦Enumeration and Record types not implemented 

PACKED is ignored on boolean arrays 

All variables and parameters are allocated statically 
Items marked with a * are being implemented in the subsequent releases of Pascal/MT. 

-6- Extensions : 

Pascal/MT contains the following extensions (in release 2.5): 

Pre-declared arrays "INPUT" and "OUTPUT" for manipulating I/O ports directly. 
EXTERNAL assembly language procedure declarations for using pre-assembled 
routines (using PL/M parameter passing) 

OPEN, CLOSE, DELETE, CREATE, BLOCXREAD, BLOCXWRITE routines for accessing CP/M files. 
Logical un-typed boolean operators for and (.&) or (J) and not if) 
18-digit 3CD arithmetic package. 

-7- Measurements : 



Compilation speed is approximately 600 lines/min. 6K bytes symbol table space is available in 
a 32K system and 38K bytes table space is available in a 64K system. Run-time code (without 
debugger), is 5 to 10 times faster than ?-code systems, and is 1.5 to 2 times larger than ?-code 
systems (but Pascal/MT requires no interpreter)* 

-3- Availability: 

Pascal/MT Release 2.5 is available immediately. 

Enhanced releases will be mace periodically throughout the next year . 

Also available from: FMG Cor^D (817) 294-2510 for TRS-80 

Lifeboat Assoc. (212) 580-0082 for all formats 



IBM 370-165 (Weizmann) 

{ See GOLEM B (Weizmann) ) 

Motorola 6800 (Dynasoft Systems) 

This is a compiler for a cassette-based system, and sells for $35. 

Dynasoft Systems 

P0B 51 

Windsor Junction, North Saskatchewan B8N 2V0 

Canada 



Mot orola 6809 (Motorola) 



MOTOROLA 6809 PASCAL - CHECKLIST FOR PASCAL NEWS 

. DATE/VERS ION 

12 December 1979 

Version 1.0 released September 1979 

Version 1.1 to be released February 1980 

l^-.IE-,[^ENTpR/DISTRIBUTOR/ MAINTAINER 

Motorola Microsystems 
P.O. Box 20906 
Phoenix, Arizona 85036 
(602) 831-4108 

2. MACHINE 

Motorola 6809 EXORciser 

3 . SYSTEM CONFIG URATION 

MDOS09 03.00 running on 6809 EXORciser with 56K 
bytes and floppy-disk drive. 

4. DISTRIBUTION 

On floppy diskette (M6809PASCLI) for $1500 from 
Motorola Microsystems 
P.O. Box 20906 

^VflloVolT* 85 ° 36 ° rderS should be P laced thr ough local 
(602) 962-3226 Motorola Sales Office or Distributor 



DOCUMENTATION 



Motorola Pascal Language Manual (M68PL.M(D1)) describing 
Motorola, implementation (56 pages). 6809 Pascal Interpreter 
User's Guide (M6809PASCLI(D1)) describing operation of 
interpreter (48 pages). 



6. MAINTENANCE POLICY 



RCA 1802 (Golden River) 



The information on this compiler is unclear. It appears to be all or 
partly in ROM, and sells f or £ 40. 

The Golden River Co., Ltd. 

Telford Road. 

Bicester, Oxfordshire 0X6 0UL 

England 



Bugs should be reported to software support. 
Subsequent releases will include corrections. 



Zilog Z-80 (Digital Marketing ) 



7. STANDARD 



( See Zilog Z-80 (Digital Marketing) } 



Restrictions: May not specify formal parameters which are procedure 
or function identifiers. Floating point numbers ere not implemented. 
Packed attribute has no effect. All will be implemented in future 
releases. Enhancements: Address specification for variables; 
alphanumeric labels; an exit statement; external procedure and 
function declarations:, non-decimal integers; otherwise clause 
in case statement; runtime file assignments; structured function 
values"; string variables and string functions. 



8. MEASUREMENTS 



Compiles in 56K bytes, 
interpreter module. 



Runtime support requires 3-4K byte 



Zilog Z-80 (Ithaca Intersystems) 



This compiler runs under CP/M and produces macro-assembler code. The 
price is $275. 

Ithaca Intersystems (formerly Ithaca Audio) 
1650 Hanshaw Road 
P.O. Box 91 
Ithaca, NY 14850 



RELIABILITY 



Mery good- 
reported. 



-first released in September 1979 with few major problems 



10. DEVELOPMENT METHOD 



One pass recursive descent compiler generates variable length 
P-code. One pass P-assembler (second release) generates a 
compact, position-independent coda for interpreter. Code and 
interpreter both ROMable for use in non-EXORciser environment. 



11. LIBRARY SUPPORT 



Zilo g Z-80 (MetaTech) 

{ See Zilos Z-80 (MetaTech) > 



Standard Pascal procedures and functions, plus the ability to 
link assembly language routines. 
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DEPARTMENT OF APPLIED MATHEMATICS 
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Pascal User r s Group 

C/o J. Miner 

University Computer Center: 227 EX 

208 SE Union St. 

University of Minnesota 

Minneapolis, MN 55455 



September 5, 1979 



Dear Mr. Miner, 

I have transported the Zurich P4 Compiler to the GOLEM B computer of the 
Weizmann Institute. Following is a checklist for Implementation Notes: 

0. Date/Version . 79/09/03 

1. Distributor/Implementor/Maintainer : 

W. Silverman 

c/o Dept. of Applied Mathematics 
The Weizmann Institute of Science 
Rehovot, Israel. 

2. Machine : GOLEM B, 370-165. 

3. system Configuration: GOBOS for GOLEM B (designed and built by WI) . Also 

— — p r oduces P-CODE on our 370-165. Variants produce 
P-CODE for the GA-16 and the Z80; a loader, written in PASCAL is available 
for the latter, and an interpreter is being checked out on our Z80 simulator 
and on the TEKTRONIX 8001/8002A ^Processor Lab. 

4 « Distribution : Source of compiler, configured for your machine as is P4, 

with a few additional parameters, and of our Loader and addi- 
tional package as they become available, on magnetic tape (9-track, 1600 BPI 
or 7-track as required) within Israel. Send mini-tape to distributor - 
mailing costs only. Special arrangements possible outside Israel. 

5. Documentation : Same as P4 system plus additional P-Code and extra parameters 
descriptions . 



CABLE ADDRESS: WEIZINST (Israel) :tPp-atA T jm PHONE: (054)82111-8*111 :TW*» TELEX: S1934 :0pbu 



8. 



Maintenance Policy : Bug reports receive prompt attention and replies. 

Various optimization programs will be announced as 
available. 

Standard: 

Extensions to P4 (Standard) ? 

Multiple global text files permitted and "FILE OF CHAR" properly processed; 
Procedure/Function may be declared as formal parameter (no run-time check 
for argument match) ; 

PACK , UNPACK , ROUND , REWRITE , RESET implemented ; 

e:el:e2 implemented for real e in WRITE-list; 

MAXINT accessible as standard constant. 
Non-Standard Extensions : 

FORTRAN, EXTERN and independent compilation option (*$E+*) ; 

Additional digraphs and operator codes (e.g. " (.",".)","&") . 

Measurements : 

- Compilation speed t 1300 characters/second (measured compiling itself; 
4442 lines x 80 characters per line in 280 seconds - 300 seconds with 
listing) . 



Compilation space: 



288000 8-bit bytes (this can be reduced somewhat 

stack/ 



from the actual 11B64.^ 4-byte words of storage, by reducing the 
lo 

heap which is nominally 128K bytes for GOLEM B - the basic level-0 stack 

requirement is 6700 bytes, plus 700 bytes per recursion level of BODY and 

a basic procedural overhead of 32 bytes per nested call) . 

Execution speed: Approximately 1/5 as fast as PASCAL 8000 on our 370/165 
(the GOLEM is intrinsically 1/2 as fast) . 

Execution space: 8.3 bytes / P-Code instruction (peep-hole optimization 
improves this figure dramatically) , plus data storage as follows : 



Item 


Size 


Allignment 


Stack element 


8 bytes 


8 bytes 


Real 


8 " 


8 " 


Integer 


4 " 


4 " 


Pointer 


4 " 


4 " 


Character 


1 byte 


byte 


Set 


1-8 bytes 


byte 


Boolean 


1 bit 


bit 



Note that Boolean arrays are optimally stored, 1-bit/element; the cost in 
access overhead is modest. Declared scalar s are represented as integers. 



9. Reliability : 

Excellent - this is primarily due to the high quality of the P4 system 
we received from Zurich. We have conserved their design and implement- 
ation principles in all modifications. Two sites, both of them at the 
WI r are currently using the system. Two others are considering it. 

10. Development Methods 

The P4 Compiler was transported to the GOLEM in approximately three months 
(real time) by one person. The P-Code is expanded as macros by our Assemb- 
ler to produce a mixture of in-line instructions and subroutine calls. 
The Assembly-language system consists of 3430 source lines, including all 
macro definitions and full run-time support. Total effort to date is 
approximately 6 man-months by professional programmers plus 2 student- 
months, included in this effort are 850 lines of modifications and ex- 
tensions to P4, written in PASCAL, replacing and extending 300 lines of 
the received compiler. 

The implementor had previously been project manager for CDC FORTRAN '63, 
supervised the development of several other compilers and written numerous 
Cross-Asemblers and Simulators; although familiar with ALGOL he had no 
previous knowledge of PASCAL. 



11. The FORTRAN and EXTERN extensions permit access to FORTRAN libraries 

(specifically NAG and IMSL) and to independantly compiled PASCAL proce- 
dures and functions. All linkage is via our system linking loader, so 
normal JCL suffices: 

e.g. a) PASCAL (SOURCE) 

EXAMPLE 
compiles and executes the program EXAMPLE from the file SOURCE. 

b) PASCAL (SI) 

PASCAL (S2,BINARYl) 

PASCAL (S3,BINARY2) 

FORTRAN (S4,BINARY3) 

LOADNAG , EXAMPLE 

EXAMPLE 
compiles 4 files and links their programs with binary and NAG routines and 
executes the resultant load-module, EXAMPLE, which has the same name (in 
this case) as the PROGRAM statement of the principal file. 

No automatic text copying is supplied, however, various editors obviate 
the need for this facility with COPY, DECK, COMDECK, COMMON and INCLUDE 
commands . 

A symbolic-dump-table option produces a symbolic file which is used by a 
PASCAL-coded Post-Mbrtem dump procedure to produce a symbolic dump (one 
new P-CODE instruction is produced for this purpose) . 



We have two Master's thesis projects developing transportable 
optimization programs for global and peep-hole optimization. I'll keep 
you informed of their progress. We're also developing a Cross-compilation 
support system to provide PASCAL capability to all the lab-computers 
(Mini's and Micro's) connected to our major computer complex. 



Sincerely, 



fr>.-, LV 



William Silverman 



OI^UJ H0>TT to Kris and Elaine Frankowski and hello to Larry Liddiard, 
et al in the Computer Science Dept. 



Intel 8085/8080 (Dig ital Marketing) 



This compiler runs under CP/M and is a Pascal-P descendant. The price 
is $350. 



Digital Marketing 

2670 Cherry Lane 

Walnut Creek, CA 994596 



GAMMA TECHNOLOGY Pascal for Data General AOS Systems 



Implementation Checklist 



0) DATE/ VERS ION: 

AOS Pascal Revision 2 - September 1979 
Checklist date: November 16, 1979 

1) DISTRIBUTOR: 

Gamma Technology, Inc. 
2452 Embarcadero Way 
Palo Alto, CA 94303 
(415) 856-7421 
TWX: 910-373-1296 

2) MACHINE/ SYSTEM CONFIGURATION: 

Data General Eclipse and M600 Series 



4) 



3) 



IMPLEMENTOR/MAINTAINER : 
Pete Goodeve 
3012 Deakin Street 
Berkeley, CA 94705 



SYSTEM CONFIGURATION: 
AOS Rev 2.00 or later 
Floating point hardware 



DISTRIBUTION: $500 package comprises a 9-track, 800 bpi magnetic tape and 
documentation (package price is $50 if it is an upgrade to a previously purchased 
release-1 system. 

Tape is in AOS dump format, containing a complete system, documentation, and 
sources. Included at no charge are some public domain Pascal utilities based on 
those supplied by the University of Minnesota. 

5) DOCUMENTATION: An instruction manual gives details of usage under AOS; a current 
textbook should be referred to for knowledge of the Pascal language itself. 

Differences from the (draft) standard (and from previous versions) are 
described in reference sections of the manual. 

An AOS "HELP" file is supplied, and also documentation for the utilities. 
All documentation is also in machine-retrievable form. 
An up-to-date list of bugs and notes will be maintained. 

6) MAINTENANCE POLICY: Bug reports (in writing) are encouraged; please send them to 
the distributor (Gamma Technology). The system is expected to be stable; no 
incremental upgrades are planned, but fixes will be distributed. Any future major 
development will depend on demand. 

7) STANDARD: The compiler is a considerably enhanced derivative of P-4 (christened 
"P-5") with many major restrictions of the original removed. 



Restrictions: 

PACKED is ignored; PACK and UNPACK are not implemented. 

DISPOSE is not implemented; heap management is by MARK and RELEASE. 

Parameters may not be Procedural or Functional. 

Subrange set constructors are not recognized. 

There are restrictions on READ and WRITE (but not on GET and PUT) for 

files either passed as parameters or coded as non-text. 

Only four text files may be in use at one time (no restriction on 

other types) . 

Enhancements over earlier versions (P-4): 

Files may be of any type (except FILE). 

Any (global level) files may be specified external in program header. 
Full ASCII is supported; lower and upper case alphabetics are equiva- 
lent identifiers. Braces may be used as comment delimiters. 



String constants may be up to one line in length. 

Format control of real output is as defined by the standard. 

TEXT and MAXINT are predeclared. 

GOTOs must be to a line within enclosing scope (standard Pascal) . 

Stack frame allocation is improved. 
Lang uag e enhanc emen t s : 

External procedures (Pascal or assembly code) . 

HALT (or HALT (n) ) abnormal termination feature. 

Random access to all files. 
AOS features: 

Compile command options (selecting e.g. cross-reference listing, 

binary only, syntax check only, etc.). 

Max stack/heap space allocated .can be specified at both compile 

and execution time. 

External files may be specified in execution command. 

8) MEASUREMENTS: No real timing tests have yet been made, but compiler compiles 
itself (on a quiet system) in 10 or 11 minutes. 

The run-time interpreter occupies about 9 Kbytes. In addition to this, and the 
space needed for the program's P-code, a default of 4K bytes is allocated for run- 
time stack and heap space; this can be increased or decreased by the user at 
compile and/or run time — the range is from 2K bytes up to the limits of the 
machine . 



it has been running at the 
managed to cause a system crash 



9) RELIABILITY: Excellent, over the two months 
development site. No Pascal program has yet 
(unlike other languages runing under AOS). 

Revision 1 is now in use at abut 20 sites, with a good reliability record. A 
few slight problems (mainly with stack overflow) found in that revision have been 
fixed in the new one. 



10) DEVELOPMENT METHOD: This is a fast P-code interpreter system. The compiler 
generates an extended, machine-independent symbolic P-code, which is then 
translated and assembled into a compact binary form; this is bound with the 
interpreter to create an executable program file. The sequence from source to 
program file is manag-ed automatically by a single user command. 

This "P-5" compiler has been developed directly from the Lancaster version of 
P-4. It should be completely transportable, except that it assumes the character 
set is ASCII. Aside from its use of HALT(n), the compiler is written entirely in 
standard Pascal. It was necessary, however, to split the compiler P-code into 
overlay segments, so that large programs can be compiled (the overlay scheme is 
not available to user programs) . 

The P-code translator is written in Pascal, and the run-time system in Eclipse 
assembly language. 



11) LIBRARY SUPPORT: Pascal cannot be linked to other languages for the Eclipse 
(except assembly language), because each has its own stack format. 

External procedure modules may be compiled separately and linked to a main 
(Pascal) program. External procedures may also be written in assembly language. 

One or two library procedures are supplied with the system (for example, for 
extra file management functions) , but no general library is envisaged aside from 
the utilities already supplied. 



IMPLEMENTATION NOTES ONE PURPOSE COUPON 

0. DATE 

1. IMPLEMENTOR/MAINTAINER/DISTRIBUTOR (* Give a person, address and phone number. V 



2. MACHINE/SYSTEM CONFIGURATION (* Any known limits on the configuration or support software required, e.g. 

operating system. *) 



3. DISTRIBUTION (* Who to ask, how it comes, in what options, and at what price. *) 



4. DOCUMENTATION (* What is available and where. *) 



5. MAI NTEN ANCE (* Is it unmaintained, fully maintained, etc? *) 



6. STAN D ARD f* How does it measure up to standard Pascal? Is it a subset? Extended? How. *) 



7. MEASUREMENTS (* Of its speed or space. *) 



8. RE LI ABI LITY (* Any information about field use or sites installed. *) 



9. DEVELOPMENT METHOD (* How was it developed and what was it written in? *) 



1 0. LIBRARY SUPPORT (* Any other support for compiler in the form of linkages to other languages, source libraries, etc. *) 
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NOTE: Pascal News publishes all the checklists it 
gets. Implementors should send us their checklists 
for their products so the thousands of committed 
Pascalers can judge them for their merit. Otherwise 
we must rely on rumors. 



Please feel free to use additional sheets of paper. 



IMPLEMENTATION NOTES ONE PURPOSE COUPON 



POLICY: PASCAL USERS GROUP 



(17-Mar-80) 



Purpose: The Pascal User f s Group (PUG) promotes the use of the programming 
language Pascal as well as the ideas behind Pascal through the 
vehicle of Pascal News . PUG is intentionally designed to be non 
political, and as such, it is not an "entity 11 which takes stands on 
issues or support causes or other efforts however well-intentioned. 
Informality is our guiding principle; there are no officers or 
meetings of PUG. 

The increasing availability of Pascal makes it a viable alternative 
for software production and justifies its further use. We all 
strive to make using Pascal a respectable activity. 

Membership: Anyone can join PUG, particularly the Pascal user, teacher, 
maintainer, implementor, distributor, or just plain fan. 
Memberships from libraries are also encouraged. See the 
ALL-PURPOSE COUPON for details. 



Facts about Pascal, THE PROGRAMMING LANGUAGE: 



Pascal is a small, practical, and general- purpose (but not all-purpose ) 
programming language possessing algorithmic and data structures to aid 
systematic programming. Pascal was intended to be easy to learn and read by 
hunans, and efficient to translate by computers. 

Pascal has met these goals and is being used successfully for: 

* teaching programming concepts 

* developing reliable "production" software 

* implementing software efficiently on today 1 s machines 

* writing portable software 

Pascal implementations exist for more than 105 different computer systems, and 
this number increases every month. The "Implementation Notes" section of 
Pascal News describes how to obtain them. 



o 

o 



The standard reference and tutorial manual for Pascal is: 

Pascal - User Manual and Report (Second, study edition) 
by Kathleen Jensen and Niklaus Wirth. 

Springer-Verlag Publishers: New York, Heidelberg, Berlin 
1978 (corrected printing), 167 pages, paperback, $7-90. 

Introductory textbooks about Pascal are described in the "Here and There" 
section of Pascal News. 



The programming language, Pascal, was named after the mathematician and 
religious fanatic Blaise Pascal (1623-1662). Pascal is not an acronym. 

Remember, Pascal User's Group is each individual member's group. We currently 
have more than 3357 active members in more than 41 countries, this year 
Pascal News is averaging more than 120 pages per issue. 



Return to: 

PASCAL USERS GROUP 
P.O. Box 888524 
Atlanta, GA 30338 



Return postage guaranteed 
Address Correction requested 



Bulk Rate 
U.S. Postage 

PAID 

Atlanta, Ga. 

Permit No. 2854 



